[Zope-dev] Packaging Zope for Fedora

[Timothy Selivanow]

On Sat, 2008-03-22 at 08:05 +0100, Andreas Jung wrote:
> In general we want to get rid of 3rd-party packages we don't want to 
> maintain on our own.

That's perfectly sane :)  There is no sustainable reason to lug around
some other project's code in yours in the Open Source world.

> Right now we have several 3rd-party packages like 
> Docutils in our svn for several reasons. Some of those packages are 
> basically frozen (because we made local changes e.g. for security reasons).
> So if you rip out those packages you have to guarantee that they will 
> _never_ be updated by a new official package (because local changes might 
> get lost). On the other hand you must ensure that changes to our local
> 3rd-party packages will be available through your packaging mechanism.
> As said: this is a challenging task for us right now - it will be even more 
> challenging and more error-prone for outsiders.

Now when I say "rip out", I don't mean repackage (make a sub RPM), I
mean remove from the RPM that I am making.  I don't want to provide a
"new" Docutils.  I'm actually trying to place zope in the standard (for
Redhat) python site-packages location while guaranteeing that the zope
RPM doesn't provide more than it needs, and doesn't clobber other
packages, like the native Docutils.

If I knew what versions the 3rd party pieces were, I could make a diff
(or the Zope project could provide one) and I could get those into the
official Fedora RPMs (esp. if they are security fixes).  Fedora doesn't
like keeping those patches forever, so I would also get those pushed
upstream.

> The trend in all Zope-related projects (Zope 2,3, Grok, Plone) is 
> definitely: self-contained installation. Why self-contained? Different 
> projects require different modules in different versions.

That is completely understandable from a Service Provider standpoint,
but not a distro.  However, coming from a Service Provider background
(my day job, as it were), I definitely like reproducibility, and a
distro package (i.e. RPM) is a good place to start.  It's very annoying
and time consuming to replicate by hand the environment that is going to
appear on several servers, esp. over long periods of time (not to
mention upgrades/security, etc...)

> Messing a Python 
> installation with e.g. ZODB from different versions will end up in an 
> disaster. So the message of the Zope community is in general: keep your 
> Python installation clean and use zc.buildout or virtualenv for installing
> your other modules within an isolated environment. This is meanwhile 
> considered best-practice. Using Python eggs and easy_install you have _the
> official_ tools in your hand for installing 3rd-party packages..that's the 
> Pythonic way to do it, not using some distro packaging tool.

One could argue that the distro over-rides all.  In a distro role, your
job is to provide the least common denominator, not cater to every crazy
developer and their environment.  They should be more than capable of
maintaining that themselves (install several different versions of
python, zope, et al. in their home dir if need be).

> This was never my point. For me it would make more sense that the packages 
> would take the official release and re-package it as a whole without 
> splitting it up. Dependency management should happen on our side as a whole,
> not on the distribution site.

Yes, but I still have to meet those dependencies.  I was just hoping
that there would be pieces (sounds like ZODB  and zope.publisher would
be good candidates from some of the other threads) that would be useful
outside of the whole Zope Application Server scope.  I assumed that as a
(open source) software project, Zope would be delighted that people were
using their code in new and creative ways.  I wanted to help facilitate
that by offering those pieces as a stand-alone library.

> I don't know how important Zope distro packages are for users. My personal
> impression is: not so important.

Developers, yes, not very important.  /Users/ on the other hand are a
completely different animal, and packages are _very_ important.  I
suppose it's a matter of semantics on what exactly a user is in which
scope.

> Zope packages at this point might be good for getting into touch with Zope but 
> for deployment packages are basically no used - but correct me if I should 
> be wrong. Since a while we have tools in place to bootstrap Zope 2/3 
> projects, Plone installations and Grok installations very easily and in a 
> reliable way.

It matters in an unattended, (e.g.) 100+ server enviro where
reproducibility is a must.

> I know that those approaches don't comply directly with your 
> package mechanisms but I would expect that the "offical" installation and 
> deployment stories by the Zope community should be taken into account (in 
> some way).

Absolutely.  Those are important.  I would be delighted to read some of
those if someone knew/had some.

> One last thought: you might check out the packaging efforts by the Plone 
> project. They provide possibly also packages for Fedora on their own (which 
> includes Zope 2 afaik (the "universal installer")). It might make sense to 
> share experiences with them and leverage from their experiences.

Sounds like they will be the next list I hit up (sigh...my number of
subscribed lists is exponentially increasing ;)  I've been kinda
following the egg-ification and zope.producer dependency reduction
threads, and it seems like all of that would be good for me too (any
packager really...)

> But don't get me wrong. I have nothing against distro-specific packages but 
> they should be done in the right way. "Right" means for the user: they are 
> consistent with the official documentation and best-practices as used 
> within the offical Zope world - "Right" for the supporters within the Zope 
> world: we don't have to deal with issues caused distro-specific packages 
> (e.g. configurations are different from the standard, paths are different 
> from the standard etc.).

Which is why I'm here asking for input.  Perhaps I didn't start out
correctly from a Zope'ish POV, but I needed to know where the conflicts
were going to show up.  If I packaged Zope as-is, placing it in (what I
would think as) the standard python site-packages, it would never pass
scrutiny because of the extra stuff it has, and would never be included
in the distro.  In older packages that /were/ in Fedora (they are no
longer...), Zope was placed in a completely isolated environment, making
it *only* useful as an web application server.

I would rather have a package that upstream approves of and participates
in, than blindly create it in a silo not caring.  It never turns out
well in the long run with the latter.


--Tim
 __________________________________________________________________ 
/ I saw a subliminal advertising executive, but only for a second. \
\                 -- Steven Wright                                 /
 ------------------------------------------------------------------ 
  \
   \   \
        \ /\
        ( )
      .( o ).