Re: Packaging Python Pyvault Style (was Re: python 2.3 for RH7.3)

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.=20
But, we cannot do it.  I've tried with sweat and blood.  It only brings=20
frustration when the Package itself (python) automatically removes=20
*any* and *all* packages that Provides: python =3D x.y.z, even if they're=20
named foobaz2.2, when python=3D2.3.4 is upgraded ... *boom*. =20

It's hard to believe ... so, take Paul's provider.spec and give it a=20
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"=20
wrapper that flipped between versions. I'd rather not repackage the=20
whole nine yards.

> > I'd like to use natural names where possible, but the RPM issue
> > with Obsoletes still lurks. =C2=A0Providing 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=20
reason and for the sake of consistency.

> > * Do we really %ghost *.pyo? =C2=A0That's what I'm doing now as an
> > experiment discussed over at fedora.us. =C2=A0I'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=20
root user runs an application with -O as the flag.  Whether executed=20
from the commandline or whether #!/usr/bin/python -O.  So, in order for=20
a clean exit on a particular python, you'd want to make sure everything=20
is gutted by using %ghost.  The reason they're not there is because the=20
intrinsic value of their existence versus the space consumption doesn't=20
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,
=2D-=20
=2Djeff