Re: Quick poll on what's best
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
Reply to: