On Mon, Jun 19, 2006 at 12:31:25PM -0500, Joe Wreschnig wrote: > On Mon, 2006-06-19 at 19:24 +0200, Raphael Hertzog wrote: > > Hello, > > > > as you may have read in the previous mail, the latest dh_python uses > > a "debian/pyversions" file to find out the Python versions that the > > packages supports but uses as fallback the XS-Python-Version field in > > order to not break compatibility with packages that have already been > > updated. > > > > For that I've written code in dh_python that re-creates the content of > > debian/pyversions from the XS-Python-Version field. However it's now quite > > clear that this XS-Python-Version field is only essential for > > python-central and as such keeping that compatbility code inside dh_python > > may be breaking the rule that dh_python tries to be agnostic (and which is > > the wish of Joey Hess also). > > So you're removing one of the control fields while adding yet another > one in your previous mail?
I must concur, this is a radical change in the approach. Also it seems to undo the reason for taking out the X?-Python-Version fields. I don't quite understand why the X?-Python-Version fields first get agreed on by everyone at debconf and then they get removed again. AIUI there is a need for database somewhere that knows what Python versions a Python package can cope with. This means that as a (new) python version gets installed or removed a helper tool can make this available to this new version including byte-compiling (or delete the byte-compiled and symlinks to modules (the way current implementations are done) stuff). For extensions a bin-NMU would be required when a new Python version gets introduced and the rest would also be done by the helper tool. Once that is done a transition of the default Python version comes almost for free. Am I correct in assuming the above is what everyone agrees with or tries to achieve? (I know it's only a rough outline) So the discussion is whether to keep the version information of a package in it's control file (and thus dpkg's database) or inside the helper tools' module storage directory. I have never seen a list of the pro's and con's of these two databases for supported python versions (which this entire debate seems to be centred about), so here my attempt: /var/lib/dpkg/status: + Independent of helper tool. + All python version info easily found (grep-dctrl). + Natural place to describe package dependencies (IMHO) - Clutters dpkg database. - Is claimed to be fragile (why??) - Uses internal dpkg interface (which is already said not to be true). /usr/lib/<helper-tool>/<package>/.version: + Does not influence dpkg at all. - Scatters version information about. - Hides the information in the helper tool directory. IMHO it looks like using the X?-Python-Version headers in dpkg's database is better. This also makes the X-Python-Policy-Version header obsolete. I'm not sure why that came in, seems not needed and no one was asking for it. The only reason why I see it being used is for dh_python to detect a new-policy package. The debhelper 5.0.37.1 way of doing was better IMHO. The final difference between python-central and python-support seems to be where they keep the byte-compiled modules. This seems to be mostly a matter of taste, but I think many troubles (involving mainly new users and upstream again being annoyed at Debian for doing things so much different cf. python-dev) can be avoided by sticking to the standard python path (as Pycentral does) and not hide the files in /var like Pysupport. Strictly speaking the (byte-compiled) modules are not variable data after all. And during an install/remove /usr needs to be writable anyway. Floris (hoping for a fruitful discussion and not too much rushing about with code until a consensus is reached, this rushing about seems to cause more harm then it does good currently.) -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
