[Zope3-dev] Re: Moving more stuff to zope.products

[Philipp von Weitershausen]

Tres Seaver wrote:
> We are definitely at a now-or-never point about this.  As a conceptual 
> exercise, imaging packaging Zope as follows:
> 
>   1) Zope is distributed as a single, monolithic chunk (all that
>      "dependency spaghetti" will allow).
> 
>   2) Each product and subsection of zope.app is packaged as a separate,
>      loosely coupled package (RPMs, .deb's, whatever) *with explicitly-
>      identified dependencies on the others.*
> 
> The first scenario makes the "what is in the core?" question crucial; 
> the second allows different "super-packages" to be created to suit 
> different needs (e.g., my "filesystem-developer only" distro would not
> preclude a separate "ttw-devel-and-the-kitchen-sink" distro).  Given 
> that the two best-known package systems (.deb / .rpm) can both do 
> dependency resolution (rpm + apt or yum, anyway), the major advantage of 
> the monolithic strategy ("batteries included") is reduced.

I really like scenario #2, especially with the option to have 
super-packages with dependencies (that's very debianic, which I like).

Looking at a package in zope.app then, it

   - would have well-defined and well-documented dependencies (maybe we
     can come up with a format that automatic build machines can create
     packages easily)

   - could very well be optional, depending whether other crucial
     packages depend on it

   - is in some sense standard though, because it's in zope.app and not
     some other top-level package.

That means, we could really dump the idea of zope.products (fine with 
me!), because packages in zope.app would already fullfil its requirements.

> Packaging for Windows and platforms without such dependency resolution 
> remains thornier;

I don't know how packaging for Windows is done, but I guess you could 
have a dependency resolution system in Python that would checkout the 
right packages from CVS and you'd only have to build that and zip it up, 
or feed it to an installer...

Same applies to MacOS X, I guess. It would be easy to get it into fink 
(since they use debian packages), but maybe it'd be nice to provide a 
.dmg distribution. If ZC can't, there should at least be an easy 
framework for others to use, so they can make packages.

> nonetheless, I think we should attempt the "fine grained" mdel.  From
> this POV, it should be a goal of PackageGeddon both to identify *and
> to reduce* such interpackage dependencies.

Yup.

Philipp