Re: python packaging infrastructure
Josselin Mouette writes: Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit : This is the right direction, and adding support for extensions makes this complete. Does your proposal allow rebuilding these packages without actually changing anything (except the changelog). Being able to rebuild packages for a new python version without changing anything was the purpose of dh_python from the very beginning, for both packaging styles: * for packages with a single python-foo package containing extension foo, build-depending on python-dev, a rebuild will generate a new package built against the new version; * for packages with python2.3-foo and python2.4-foo, a rebuild will make python-foo depend on the new version. The only case that isn't handled is when the package isn't maintained much, and lacks python2.5-foo when the python2.5 transition approaches. This is independent of python-support. the design decision of putting the binary-all python packages in a separate directory into /var/lib/python2.x/site-packages has some problems when supporting packages with extensions (a proposal beeing made on #irc was to keep the extensions in the standard path). suppose you have the following scenario /usr/lib/python2.3/site-packages/foo/ __init__.py fooext.so (doing a import foomod) foomod.py which is splitted into (by python-support) /usr/lib/python2.3/site-packages/foo/ __init__.py fooext.so /var/lib/python2.3/site-packages/foo/ __init__.py foomod.py Having /var/lib/python2.3/site-packages appended to sys.path let's the import of foomod fail (cannot be found). Using just one package directory inside /usr/lib/python2.3/site-packages does avoid the problem (the way the current python-central works). Matthias
Re: python packaging infrastructure
Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit : the design decision of putting the binary-all python packages in a separate directory into /var/lib/python2.x/site-packages has some problems when supporting packages with extensions (a proposal beeing made on #irc was to keep the extensions in the standard path). suppose you have the following scenario /usr/lib/python2.3/site-packages/foo/ __init__.py fooext.so (doing a import foomod) foomod.py which is splitted into (by python-support) /usr/lib/python2.3/site-packages/foo/ __init__.py fooext.so /var/lib/python2.3/site-packages/foo/ __init__.py foomod.py Having /var/lib/python2.3/site-packages appended to sys.path let's the import of foomod fail (cannot be found). Using just one package directory inside /usr/lib/python2.3/site-packages does avoid the problem (the way the current python-central works). As I already explained on IRC, dh_python will not hand .py files to python-support in architecture-dependent packages containing a .so module. This is unnecessary and would bring issues like this one. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: python packaging infrastructure
Josselin Mouette writes: Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit : As I already explained on IRC, dh_python will not hand .py files to python-support in architecture-dependent packages containing a .so module. This is unnecessary and would bring issues like this one. So how does python-support handle packages, where the extension module is split out in it's own binary package? I'm not convinced to support a build infrastructure in python which only serves some part of python packages. Matthias
Re: when and why did python(-minimal) become essential?
debian-python Cc'ed On Wed, Jan 18, 2006 at 07:02:32PM -0600, Joe Wreschnig wrote: This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. So why does Debian need/want python-minimal? (This is a question mostly for Matthias, I think, but if you know the answer that's great.) Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system * allowing us to provide python early on installs to make users happier I don't know what's actually in (or more importantly not in) python2.4-minimal though. I think unless there's a bit more discussion about this I'll remove the python-minimal package, and encourage Joerg to be a bit more careful before accepting it again. If it's not going to be in base or required, or even more minimal than python2.3, I can't see much point to keeping it around. Cheers, aj signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 12:12:07PM +1000, Anthony Towns wrote: debian-python Cc'ed On Wed, Jan 18, 2006 at 07:02:32PM -0600, Joe Wreschnig wrote: This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. So why does Debian need/want python-minimal? (This is a question mostly for Matthias, I think, but if you know the answer that's great.) Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal But it really doesn't provide compatibility with Ubuntu unless it's Essential, given that no packages from Ubuntu are going to be depending on it (being Essential)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote: debian-python Cc'ed On Wed, Jan 18, 2006 at 07:02:32PM -0600, Joe Wreschnig wrote: This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. So why does Debian need/want python-minimal? (This is a question mostly for Matthias, I think, but if you know the answer that's great.) Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal This would be nice. Right now it's accomplished through patches Ubuntu makes to dh_python and cdbs. They'd probably like to drop those. * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system I wouldn't mind this, but it does seem to be somewhat against the definition of base. * allowing us to provide python early on installs to make users happier This feels weak to me; it applies equally well to any language a user might want. I don't know what's actually in (or more importantly not in) python2.4-minimal though. I'm eyeballing right now. Things that jump out at me: * No character encoding, translation, or locale handling. * A little oddly, loss of shutil. * No sockets. The first one seems like it would be a show-stopper to me, unless we expect programs in the base system to only deal with ASCII. This is a fairly large addition to package, too. The second can easily be fixed; possibly just oversight. It's a small module and gives Python equivalents of cp -r, rm -r, and mv. The third seems like something software in base may want to do; I mention it specifically because perl-base include socket support. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 12:12:07PM +1000, Anthony Towns wrote: * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system * allowing us to provide python early on installs to make users happier Please note that it is against upstream's explicit wishes for -minimal to be installed for users as part of a package selection which does not also include the full python package. In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). I don't know what's actually in (or more importantly not in) python2.4-minimal though. We basically reviewed the available modules and picked out the ones that we thought would be useful in an Essential context, with a goal of having no external non-Essential dependencies. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
