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

Jeff Pitman symbiont at berlios.de
Mon Dec 20 07:56:41 CET 2004


Taking this to repo-coord, since there are several Python packagers that 
potentially want to comment on these issues.  Hope that's okay.


Normally, I'd thread my responses with the email that was sent, but it's 
a little unwieldy and I hope all can get the context with which this 
discussion was started with.  I'll include the original piece for 

Anyway, the request was given that an RPM named "python" be provided 
that does some housekeeping and symlinks without using alternatives in 
the version-specific pythons (python23, python24).  However, there is a 
weakness in RPM where it will automagically Obsoletes previous versions 
of Python when executing an Upgrade.  I've tried this 1 billion ways 
already and it doesn't work.  In addition, there are /usr/bin/* 
programs supplied with libs like PyXML that could be alternative'd, but 
the current version inside of chkconfig that comes Redhat cannot handle 
dealing with alternatives spanning across a set of packages.

Earlier in the year, I've sent a draft Nomenclature document which I 
have updated with your ideas and tried my best to implement all of your 
input into this repo.  But there are a lot of limitations that we need 
to work around while trying to obtain the ultimate goal of the 
repository of itself. This is stated in the document.

Please see the updated document here:

The scope of the document is expanding, so in the near future I'll 
probably rename it to the Pyvault Python Policy to reduce confusion.  
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).

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.  

On a side note, Debian folks have already hashed back in forth about 
Python policies ahile ago.  Looks like we're behind the times. ;-)


They're workarounds were different than the ones we need, but 
nonetheless useful to learn from.

Open items that need to be resolved:

* 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)

* I'm certain there's more ...  :)

take care,

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?


More information about the PyVault-devel mailing list