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

[Jeff Pitman]

On Monday 20 December 2004 19:13, Axel Thimm wrote:
> > 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)?

Ahhh!  The *invisible* obsoletes, of course!!

http://distro2.conectiva.com.br/pipermail/apt-rpm/2004-August/002513.html
http://lists.atrpms.net/pipermail/repo-coord/2004-August/000357.html

I mean, I like your idea.  It maps closer to Debian Python Policy, etc. 
But, we cannot do it.  I've tried with sweat and blood.  It only brings 
frustration when the Package itself (python) automatically removes 
*any* and *all* packages that Provides: python = x.y.z, even if they're 
named foobaz2.2, when python=2.3.4 is upgraded ... *boom*.  

It's hard to believe ... so, take Paul's provider.spec and give it a 
shot:
http://people.redhat.com/pnasrat/provider.spec

> > 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 [...]

I'd rather choose between educating users via FAQ or build a "python" 
wrapper that flipped between versions. I'd rather not repackage the 
whole nine yards.

> > 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?

See above. The names are just pythonXY and pythonXY-module for this 
reason and for the sake of consistency.

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

Well, if one does not package .pyo, they'll possibly get created if a 
root user runs an application with -O as the flag.  Whether executed 
from the commandline or whether #!/usr/bin/python -O.  So, in order for 
a clean exit on a particular python, you'd want to make sure everything 
is gutted by using %ghost.  The reason they're not there is because the 
intrinsic value of their existence versus the space consumption doesn't 
match up. YMMV--just a blind experiment, I guess.

This piece has a good summary:
https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00249.html

take care,
-- 
-jeff