Zope2 packaging

[Jonas Meurer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

Am 24.06.2011 02:33, schrieb Jonas Meurer:
> Am 21.06.2011 14:02, schrieb Arnaud Fontaine:
>>     > Are you ok with me uploading zope2.12 packages within the next two
>>     > weeks?
> 
>> I can perform a last review later  this week as I'm too busy until then,
>> but I think  it could be uploaded before,  no?  BTW, is debian/copyright
>> ok?  If not, I can double-check it when reviewing.
> 
> In my opinion some issues are left before the zope2.12 packages can be
> uploaded to Debian. I would like to hear your comments about that:
> 
> 1. Please review debian/README.source and enhance where appropriate.
> 
> 2. What shall we do with the egg-info folders? Are they required to be
> installed alongside the modules? Currently every included egg installs a
> subdirectoy 'EGG-INFO' into /usr/lib/zope2.12/lib/python/<egg>. To my
> knowledge these directories are useless, and should be removed from the
> binary package. What do you think?

After checking other Debian python packages I don't have a strong
opinion on that any longer. It seems like the EGG-INFO folders are
shipped inside a lot of Debian python binary packages. Still I don't see
a reason to ship them within the zope2.12 package, but we can decide on
that later.

> 3. It seems like not all zope dependencies are pushed into the tarball
> by Michaels debian/scripts/fetch.py. If I compare the list of
> dependencies in versions.cfg and the list of installed dependencies, a
> lot are missing even though not listed in DEB_SATISFIED. These are:
> 
> buildout.dumppickedversions, jinja2, lxml2, pygments, python-gettext,
> roman, sphinx, unittest2, z3c.checkversions, zc.buildout, zc.recipe.egg,
> zc.recipe.testrunner, zodbcode, zope.app.apidoc,
> zope.app.applicationcontrol, zope.app.authentication, zope.app.broken,
> zope.app.cache, zope.app.catalog, zope.app.content, zope.app.dav,
> zope.app.dtmlpage, zope.app.error, zope.app.exception, zope.app.file,
> zope.app.folder, zope.app.generations, zope.app.http, zope.app.i18n,
> zope.app.interface, zope.app.intid, zope.app.locales,
> zope.app.localpermission, zope.app.principalannotation,
> zope.app.renderer, zope.app.rotterdam, zope.app.security,
> zope.app.securitypolicy, zope.app.server, zoper.app.session,
> zope.app.traversing, zope.app.undo, zope.app.wsgi, zope.app.zapi,
> zope.app.zcmlfiles, zope.app.zopeappgenerations, zope.app.zptpage,
> zope.catalog, zope.decorator, zope.documenttemplate, zope.index,
> zope.keyreference, zope.modulealias, zope.principalannotation,
> zope.principalregistry, zope.securitypolicy, zope.server, zope.thread
> 
> Some of them are clearly not required (buildout stuff), and some might
> be installed as python modules packages (jinja2, python-gettext, ...),
> but I still wonder why they aren't pushed into the tarball by fetch.py
> despite not being listed in exclusions. Michael, maybe you have an idea?

This one is more important. But I have a suspcion why this happens now.
fetch.py uses pip to fetch "Zope2==2.12.18", which fetches all
dependencies of Zope2 as well.
First I thought that all packages that are listed in versions.cfg would
be fetched, but that seems to be wrong. I'm not sure yet whether I got
the purpose of versions.cfg, but it seems like get_specs() uses it to
override versions from the list of Zope2 dependencies. It's unclear to
me why this is required, but I guess PIP/buildout internals are the reason.

Michael, maybe you can add a short comment on this?

> 4. Generally I'm not sure whether all listed dependency eggs are really
> required to be installed inside the zope2.12 binary package (or listed
> as dependencies). The python distribute modules for example are used for
> setup tasks, and I don't believe that they're required for the zope2.12
> application server to run. It's more likely that the zope build system
> uses them. Thus it's important to list them in build-depends, but
> they're not required in depends.
> 
> Do you know a good way to check whether the modules in dependencies are
> really used by the application server?

Didn't further look into this one yet, but I guess that we can filter
out unneeded packages later.

Now that I understand fetch.py a bit better, I think it's ok to upload
it as-is. Do you have comments, suggestions?

I'd really appreciate to hear your opinions before actually uploading
the packages to Debian/unstable.

Greetings,
 jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOBP9/AAoJEFJi5/9JEEn+aLkQAIfrPchsYr3M3XjWklUtx/k7
SwnYVZiJg46hOE1WzPSVKJKNItYm18iQq951fQThLO7RVXaNsr/K7H1ProwFYStP
M0+FsthCmm3I1lhVcXFIXCwWBl6c5TsDIwczv66tCQnDbqM8fHk3+u7NpaCRK7Om
L3tieWWyL7j/s3sFnZnfKTCaegTbehEJ53J0chC4pxp9xkEkO+JtW0YUaomfQ4TC
Vxhn5sQJGQZnycrQq1LvzlAqXldD+pJqDVARvoPk6p1EecnG8Ydo2sMGsVjM77t+
Vb+i4EdVU+GysseGj8OU9IeOE8LjbTx5CTesVIh/BHQHYOHtWc+5LVHbpioGlA/v
M/bWz2iJK9K/kLwHSMHd/YGbXqv3KJZ+aGF2xRiJ8Yq7gKdfzPu+WXYyfBwevs/2
5GR79gEK63E5Q9Ex2Hf/pepgEsS+J9uKapQNnmygZdstHbW5HueV/daoshpWDcMu
V31PlrOBWuik5VSo6q/lLKlBrPyCwJ205eUOnHOB7LZ/BeNKGcCCeWIx+HrLErjh
6XkGBDfRzd2eMK0sIP7D3nmi/6SNvZFPUyspHeow3DafRbfKSWsoDqYsJlqbb73n
XNIMSXdDRlFS1hS0DZ03O86l/8cD7GueJX+dmUoPc90R2685OZPT6r/Ggd3ypH/n
jIWcPVArRtUk0bbvpAxY
=4GyC
-----END PGP SIGNATURE-----