Le mardi 04 septembre 2007 à 08:28 -0700, Toshio Kuratomi a écrit :
> 1) Do we want to create eggs where they aren't provided upstream. I see
> that Debian's python-docutils package doesn't provide eggs in Etch but
> you guys were willing to provide one after getting a bug report
> requesting it. Is this the general Debian policy? Package by package?
> Start providing eggs for everything distutils based? So far, the
> Fedora position has been that setuptools/eggs provide the equivalent of
> an API and therefore we should let upstream implement it, not do it
> ourselves. This could change with good arguments.
Currently, we are providing it when there is no other choice. As more
and more mislead upstream developers are using eggs, we sometimes need
them for some dependencies, but currently the de facto policy is not to
generate them unless needed.
BTW I've just learned from your reply that python2.4 in Debian was
patched to create eggs for distutils packages. This change was decided
unilaterally by the python maintainer without being discussed here. I
can understand the rationale for it, but I don't like the idea of
encouraging more upstream developers to use eggs.
> 2) We're deciding how we want to make packages when we want to have
> multiple versions of a module. For instance cherrypy is on release
> 3.0.2 but the TurboGears framework requires a 2.2.x version. So we need
> to provide both versions to our users. I've been drafting guidelines
> for doing this using eggs[1]_ but some recent discussions with Phillip
> Eby[2]_, setuptools author are proving there are some difficulties to
> doing this. Have you guys considered doing anything like this?
We don't and we won't ship eggs in Debian packages; we were happy enough
to be able to ship .egg-info files instead.
I don't think shipping supporting several versions of a package is a
good thing in a distribution, and this should remain an exception rather
than a rule. For cases like TG/CherryPy, you can imagine several
solutions:
* a conflict between both, like currently in Debian, this is far
from ideal;
* shipping version 2.x in a private directory and patching TG to
add it to sys.path;
* renaming version 2.x to something like cherrypy2;
* use alternatives like we used to do for pygtk, but this worked
very badly.
Ideally TG should be made compatible with version 3 if this isn't too
complicated.
> These are my current goals for multiple versions:
> 1) import MODULE should import whatever the vendor decided should be the
> default.
> 2) requires.txt in a project's egginfo should work to select a specific
> version from the installed eggs.
> 3) In a simple script (without requires.txt),
> should work to select a specific version from the installed eggs.
>
> I think #3 is the stumbling block as Phillip is insisting that we need
> to use easy_install to generate script wrappers that make the import
> order work rather than having an API that we can count on working. I
> have to do some more experimentation based on his last post then ask why
> he thinks that.
I don't think you need listen to anything the setuptools developers say,
as they have close to zero understanding of the packaging issues they
create for us.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=