[PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3)

Axel Thimm Axel.Thimm at atrpms.net
Mon Dec 20 12:13:04 CET 2004


On Mon, Dec 20, 2004 at 02:56:41PM +0800, Jeff Pitman wrote:
> On Sunday 19 December 2004 20:01, Axel Thimm wrote:
> > I've been doing some thinking around this. How about the following
> > scheme, which is almost already what pyvault does:
> >
> > python15
> > [...]
> > python22
> > python23
> > python24
> >
> > are packages that don't conflict/overlap and also have no
> > alternatives/symlinks etc. Using python means calling it as python2.4
> > etc.
> >
> > All python module/app packages built should get their
> > "#! /usr/bin/python" replaced with the matching python version they
> > were built against. So every python package pulls in the right
> > pythonXX package and uses it independently of /usr/bin/python
> > settings.
> >
> > And then there are "python" packages that just setup the symlinks in
> > bin for the vendor and user (e.g. python on RH7.3 still points at 1.5
> > for compatibility's sake. These packages are not really needed for
> > pyvault package to work.
> >
> > python-devel package should always point to the latest available
> > python in pyvault. That ensures that you can always use
> > "BuildRequires: python-devel >= ..." w/o using any numbered python
> > (=> no specfile editing when rebuilding other than tags). For
> > packages (build)requiring an older python the explicit pythonXX-devel
> > tags can be used to lock it onto a python version.
> >
> > On the python module/app package versioning: I'd skip the python
> > version built against (just like perl and C do not include the perl
> > or glibc version against their were built) and use natural names.
> > After all when pyvault supports a new python on all distributions,
> > all package will be built against it, and the few that need fixing
> > will just depend on a slightly older python.
> >
> > I.e. the use model assumes that the pyvault maintainer and
> > packager(s) test a new python version, approve it for becoming the
> > next base version and rebuild everything against it. pyvault also
> > provides the compatibility packages for other python packages not
> > included in pyvault (like the vendor's), and also some python
> > packages that won't build against the latest approved python version.
> >
> > It is also more maintainer friendly (i.e. don't support package pyfoo
> > on multiple different python version, only one one).
> >
> > Does that model sound OK for you?

> However, there is a weakness in RPM where it will automagically
> Obsoletes previous versions of Python when executing an Upgrade.

Which obsoletes are you thinking of? Are any really needed (other than
replacing the vendor python with the pythonXX packages)?

> But, the gist of it is to make available a set of packages that 
> maintains compatibility with existing python packages without impacting 
> those that Pyvault does not maintain (system-config-* and friends).

That's perhaps unavoidable. If a pyvault user wants to have
/usr/bin/python point to python 2.4 for his own pleasure and
system-config-* and friends break with it, the you either need to
educate users to use /usr/bin/python2.4 or rebuild applications to
burn in the python version (like "#! /usr/bin/python2.2"). Here is a
macro for that purpose:

%python_burninversion find . -type f | grep -l "^#!.*python" | xargs perl -pi -e's,^(#!.*python)([^0-9.]*|$),${1}%python_version$2,'

> I'd like to use natural names where possible, but the RPM issue with 
> Obsoletes still lurks.  Providing unique package names with the 
> versioned Python inside of it is the only way to prevent this.  

I still don't see where the obsoletes enter. You mean python module
packages, not the python packages, right? Why should python module
ackages obsolete something?

> * Do we really %ghost *.pyo?  That's what I'm doing now as an experiment 
> discussed over at fedora.us.  I'm not sure if Extras will have this 
> policy or not.
> * Need to re-bytecompile applications for the latest version of python. 
> (see http://www.fifi.org/doc/mailman/README.Debian)

Isn't this only an issue when installing into non-versioned python
dirs, which one should not do? :)

We aren't ghosting /urs/lib/lib*.so.* either with sources autobuilding
when a new glibs/gcc is installed :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pyvault-devel/attachments/20041220/ac8767ad/attachment.pgp


More information about the PyVault-devel mailing list