Re: python-central vs python-support
On Sun, 04 Jun 2006, Matthias Klose wrote: > > - python2.x-* packages -- are they needed? desirable? > >Steve and Matthias gave different answers, and if they're present > >migrations end up just as fragile as they are now. > > No, not different answers. They may be needed, if an extension get's > too big to be included in one package, or if the maintainer of the > package does not want to package it that way. The consequence is that If we change policy, then all packages should follow it. I don't think we have discussed the possibility to let real python2.X-foo packages exist any longer. Any such package will create some complicated dependency handling that we want to avoid. > every module or extension depending directly or indirectly on it must > be packages using the python2.x-* schema or else the dependencies are > broken for non-default python versions. That's precisely why we don't want to have real python2.x-foo packages. :-) However the Provides: python2.X-foo are not a problem. > > This IMO is the most important part. It's here, and we're using it. > > python-central has "right arond the corner" for months. Many modules are > > already using -support, and it integrates very easily with any project > > using distutils. With proper debhelper integration it would be even > > simpler. > > it's incomplete, doesn't support extension modules, and the author did > already refuse to support these, stating that this would be too > complicated. No status change in the last months. Sorry I don't see how python-central "supports" extension modules. I looked your python-imaging examples and you just put .so files in /usr/lib/python2.X/ ... python-central is not involved there. python-central is apparently only needed to bytecompile .py just like python-support. The rest is dh_python / dh_pycentral stuff which is not really related. Please tell us precisely what python-support should do to match your expectations. > I'm going to upload python-central to unstable tomorrow, including a > dh_pycentral debhelper, which could be included in debhelper as > dh_python as well. Would you add the required shell snippet to support python-support directly into the python runtime (just like you added the "pycentral rtinstall [EMAIL PROTECTED]@-minimal" in python2.4-minimal's postinst) if someone provided it to you ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-central vs python-support
On Sun, 04 Jun 2006, Joe Wreschnig wrote: > policy is. So here's *my* attempt at summarizing the BoF, based on your > first mail and responses, and independent of the tools used: > > 1) Public modules and extensions should support all available Python > versions, using a single binary package. > > 2) A new control field, XC-Python-Version will be used to determine what > versions of Python a module supports. > > 3) The tight upper bound on module dependencies will be removed, > provided the module actually works on future versions of Python. The > upper bound on extension dependencies will not, because then they > wouldn't work. > > 4) python2.x-* virtual packages are to be used only when necessary, but > packages can provide them regardless. > > 5) Private modules and applications should use some way to support more > than one Python version, if possible. > > Is this accurate? 1), 3), and 4) contridict your original email, but > match what you told me this time. Yes, this is a good summary IMO, however I don't remember if we discussed point 5. > 4) I am still unsure of, because Steve and Matthias gave different > answers, and your answer is confusing -- if they're desirable, let's > make them required; if not, let's not pollute the (virtual) package > namespace unless we need them for a specific reason. The reason exists, those virtual packages are needed to properly express dependencies of an application which uses a non-current python version. However very few apps are in that case so we said that we might only add the provides on the few modules which are really concerned. > 2) is suspect. It's not required for multiversion support *in policy*. > The working python-support implementation in unstable, while still > lacking such fields, proves that. I feel it's much more of an > implementation issue than a policy one, and so if we don't use > python-central (which I gather is the impetus for it), we shouldn't > bother with the control field either. Right. However Steve agreed that having this information in Packages.gz file would ease extraction of lists of packages which have to be bin-NMUed for a python transition. I had the same reservation than you on this issue. But on the other hand it doesn't hurt much to require that field if we have the required support in dh_python. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: RFS: python-musicbrainz2
Hi, I initially sent this e-mail only to [EMAIL PROTECTED], but then I realized that it's more likely to find a sponsor for a Python module here. Original Message Subject: RFS: python-musicbrainz2 Resent-Date: Sun, 4 Jun 2006 08:15:12 -0500 (CDT) Resent-From: debian-mentors@lists.debian.org Date: Sun, 04 Jun 2006 15:17:37 +0200 From: Lukáš Lalinský <[EMAIL PROTECTED]> Newsgroups: gmane.linux.debian.devel.mentors Hi, I'm looking for a sponsor for python-musicbrainz2 package. python-musicbrainz2 is a client library, written in Python, for accessing MusicBrainz data using the new MB XML web service. It's released under BSD license. The package itself is using cdbs, I tried to keep debian/rules as simple as possible. It's linda and lintian clean. ITP bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370255 And the package files: http://users.musicbrainz.org/~luks/ubuntu/dists/sid/main/source/python-musicbrainz2_0.3.1-1.diff.gz http://users.musicbrainz.org/~luks/ubuntu/dists/sid/main/source/python-musicbrainz2_0.3.1-1.dsc http://users.musicbrainz.org/~luks/ubuntu/dists/sid/main/source/python-musicbrainz2_0.3.1.orig.tar.gz Thanks. -- Lukáš Lalinský -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-central vs python-support
Steve Langasek <[EMAIL PROTECTED]> writes: > No. An extension has to be separately *compiled* for each python version > it's to support. A python-foo package containing > /usr/lib/python2.3/site-packages/foo/foo.so and > /usr/lib/python2.4/site-packages/foo/foo.so must not claim to be compatible > with python (>= 2.5). I'm not that silly... > However, it *should* be possible to provide a toolchain such that this > python-foo can be binNMUed when python-2.5 becomes available and > automatically pick up support for it. That's what i suggested in other words. If we can rely on python-all (or any other mean to get the list of supported versions), and as we already have the list of package-specific supported versions (via .version in python-support for example), so that every version is compiled without having to care to provide the list of versions manually, so transitioning becomes seamless. CDBS could be enhanced to generate all the necessary rules, so managing python packages would be painless. So, that's my idea, willing to automatize all complicated build rules, and remove the upper boundaries in dependencies, which would be rendered useless by intelligent binNMUs. So ok, this is quite some work, but this could be done on time. Transitioning scripts-only packages has already begun and can be accelerated while we work on the scripts for compiled modules, so only minor dependency updates would have to be done. -- Marc Dequènes (Duck) pgpKtPuZ0Qt57.pgp Description: PGP signature
Re: python-central vs python-support
Of course, i'd be glad to help concretly. I'm not a Python expert, but i could help on the CDBS front, and test solutions (like i did with Joss for python-support recently), and provide some valuable documentation (even if the CDBS documentation forked, i'm still updating the original version regulary). -- Marc Dequènes (Duck) pgpo1khgDA37J.pgp Description: PGP signature
Re: python-central vs python-support
On Mon, Jun 05, 2006 at 02:23:45PM +0200, Marc Dequènes wrote: > So, that's my idea, willing to automatize all complicated build rules, > and remove the upper boundaries in dependencies, which would be rendered > useless by intelligent binNMUs. Er, I guess you do understand since you agreed with my previous mail, but just to be clear, I'm going to spell it out to make sure everyone is on the same page: - An Arch: any python-foo extension package must depend on python (>= $minver), python (<< $maxver+1), where $minver is the earliest python ABI that it includes a compiled extension for and $maxver is the latest python ABI that it includes a compiled extension for. - These $minver and $maxver values should not be hard-coded in debian/control; they should be automatically populated via a substvar that's set by the same tool that knows how to handle doing the multiple binary builds (if required). - binNMUing such a package becomes possible to change either $minver or $maxver as needed without any requirement of source edits. -- 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: python-central vs python-support
On Mon, 2006-06-05 at 14:23 +0200, Marc Dequènes wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > No. An extension has to be separately *compiled* for each python version > > it's to support. A python-foo package containing > > /usr/lib/python2.3/site-packages/foo/foo.so and > > /usr/lib/python2.4/site-packages/foo/foo.so must not claim to be compatible > > with python (>= 2.5). > > I'm not that silly... > > > However, it *should* be possible to provide a toolchain such that this > > python-foo can be binNMUed when python-2.5 becomes available and > > automatically pick up support for it. > > That's what i suggested in other words. If we can rely on python-all (or > any other mean to get the list of supported versions), and as we already > have the list of package-specific supported versions (via .version in > python-support for example), so that every version is compiled without > having to care to provide the list of versions manually, so > transitioning becomes seamless. CDBS could be enhanced to generate all > the necessary rules, so managing python packages would be painless. CDBS is not necessary; look at python-gst0.10's packaging. The versions it's built for is controlled entirely via a single Make variable, and it uses regular debhelper. This could be further refined to find all installed versions of Python at build time, and simplified because everything would be in the same binary package (so it wouldn't be limited by debian/control). New tools aren't needed to make binNMUs easier, though they can do that too. A few policy changes (mostly what I outlined in my last mail) would be enough to do that with existing tools and minimal trouble. New tools are mostly needed to prevent rebuilding at all (by fixing byte-compilation issues). -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: python-central vs python-support
Steve Langasek <[EMAIL PROTECTED]> writes: > - An Arch: any python-foo extension package must depend on > python (>= $minver), python (<< $maxver+1), where $minver is the earliest > python ABI that it includes a compiled extension for and $maxver is the > latest python ABI that it includes a compiled extension for. > - These $minver and $maxver values should not be hard-coded in > debian/control; they should be automatically populated via a substvar > that's set by the same tool that knows how to handle doing the multiple > binary builds (if required). > - binNMUing such a package becomes possible to change either $minver or > $maxver as needed without any requirement of source edits. I'm fine with this. Generation of boundaries virtually removes boundaries (meaning no arbitrary boundaries remains). :-) -- Marc Dequènes (Duck) pgp4nk3doVsTC.pgp Description: PGP signature
Re: python-central vs python-support
Joe Wreschnig <[EMAIL PROTECTED]> writes: > CDBS is not necessary; look at python-gst0.10's packaging. The versions > it's built for is controlled entirely via a single Make variable, and it > uses regular debhelper. This could be further refined to find all > installed versions of Python at build time, and simplified because > everything would be in the same binary package (so it wouldn't be > limited by debian/control). I never said CDBS's use should be enforced in the policy. But this tool is used more and more, and even people in QA (which were mostly reluctant to accept it) must agree this helped improving quality (see how few people in the GNOME Team manage so many packages and transitions more efficiently). This said, CDBS is not The Final Packagingsystem, but could be eXtended (;-) so as to provide a well tested class for the so many people already using it. python-gst0.10 could be a good example, thanks for the advice. > New tools aren't needed to make binNMUs easier, though they can do that > too. A few policy changes (mostly what I outlined in my last mail) would > be enough to do that with existing tools and minimal trouble. I do agree, it is not necessary ; but would you object if continue using it because i feel confortable with ? I see no problem in advertising tools, as soon as nobody is obliged to use it. > New tools > are mostly needed to prevent rebuilding at all (by fixing > byte-compilation issues). That's _not_ true. CDBS is merely a collection of scriptlets and associated rules over debhelper, itself a collection of scriptlets, both providing well tested solutions to common problems. It is not just a matter of rebuilding, but a matter of diminishing maintainer's silly parts of the job and improving overhaul quality. In a certain ancient time debhelper was uncommonly used and badly critized, with people even rejecting to try it, now came the same time for CDBS... This is coming quite out of topic. I just suggested to help providing a class for people using this tool, *no more*. -- Marc Dequènes (Duck) pgp8qoP61sZYW.pgp Description: PGP signature
Re: python-central vs python-support
> > s/available/supported/. we will try to keep the number of supported > > python versions/implementations minimal. > > Is there difference between available and supported versions ? What use > for an official python package if it is not supported ? assume we want to add a python2.5 package. It's nice to have, but extensions will need an update, or they will FTBFS. At this point I would rather not see python2.5 as supported. > > Plus XS-Python-Version, from which XC-Python-Version is generated from. > > Why is this necessary ? You said you plan on having a dh_pycentral > script, why can't this one do the job automagically ? Why having the XC- > remain in package information then ? The 'Provides: python2.3-foo, python2.4-foo' is missing for all packages with private modules and scripts (without shared modules). For that case we do need XB-Python-Version. If we do want to drop the Provides for packages where they are not needed, we need it for shared modules as well. > >> 3) The tight upper bound on module dependencies will be removed, > >> provided the module actually works on future versions of Python. The > >> upper bound on extension dependencies will not, because then they > >> wouldn't work. > > I don't see any reason to keep this boundary, really, as you plan to use > binNMUs on transitions. Either the extension does not work on a newly > uploaded python version after being binNMU-ed, then this is a bug (not > grave), or you use a boundary for an extension which would have worked > perfectly and this is a bug too. As this is of the same severity, i > would rather have to consider a bug for an upstream lack of support for > a new version rather than for my extensions because of fear. this kind of dependency doesn't hurt, if the extensions are available for the two versions used in the transition. > >> 4) python2.x-* virtual packages are to be used only when necessary, but > >> packages can provide them regardless. > > > > you don't know in advance, if they are necessary. Not a problem, if > > they are generated. > > Yes i agree. But what a pollution. Now when Ruby and other langages would > do the same, i'd like to know how long apt would be... does apt takes a performance hit with unused provides? Well, really, just stop adding new packages to unstable has the same effect ;) > >> 2) is suspect. It's not required for multiversion support *in policy*. > >> The working python-support implementation in unstable, while still > >> lacking such fields, proves that. I feel it's much more of an > >> implementation issue than a policy one, and so if we don't use > >> python-central (which I gather is the impetus for it), we shouldn't > >> bother with the control field either. > > > > we agreed to use this information so that you can decide on package > > rebuilds based on the Sources and Packages files. See my slides from > > Debconf. > > Where are those slides ? http://people.debian.org/~doko/pycentral/ > Should we be aware where your things are stored ? yes, see http://lists.debian.org/debian-python/2006/05/msg00062.html > Don't you think this new field and Provides are redondant, and that you > could decide which rebuilds are necessary from it ? no, not for packages with private extensions. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-central bug
Piotr Ozarowski writes: > I have just finished my first python-support based package[1] and I think I > have found a bug: after running post install command: > > # pycentral pkginstall python-enchant > > I'm getting this: > | /usr/bin/python2.3: can't open file '/usr/sbin/py_compilefiles' thanks, fixed for the next upload. > BTW: I have followed python-imaging package example and installed > C sources to /usr/include/python2.X/package/ directories. Is it obligatory > to include them? python-central seems to not use them and I don't see a > reason to include them, specially duplicating that files for every python > version python-central doesn't touch the header files. I would consider the header files as version specific. have one header be generated and including the python version ... Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
