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

On Tuesday 21 December 2004 02:38, Axel Thimm wrote:
> On Mon, Dec 20, 2004 at 11:53:12PM +0800, Jeff Pitman wrote:
> > 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!!
> > [..]
>
> Yes, I see, but is there need to provide "python" in all packages,
> especially the pythonXX ones? Most packages that explicitly require
> python do so with ">=3D".

To make it so that system-config-*, and others, don't get removed.  To=20
also allow for python23 or python24 to replace python without affecting=20
other packages currently in the system.  It's the implicit requires=20
that really bite on these issues.

> > > 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.
>
> OK, then you have no issues at all with obsoletes, as the users only
> get to see pythonXX packages with no such provides, and keep their
> vendor python rpm (which does the provides/obsoletes game with his
> ancestors only).

Not sure what you mean here, but there are pythonXY rpms.  If the vendor=20
python rpm happens to Provide: python-abi =3D X.Y, then whatever I have=20
as modules should be good to go.  Building the SRPM will be difficult,=20
as that currently BuildRequires: python23-devel.  So, as of now, the=20
goal is:
	1. To replace the vendor python rpm.
	2. To provide latest python module and app packages.
	3. To keep intact existing python module and app packages Pyvault has=20
yet to deal with or does not want to deal with.

> Only python developers need to take care to have proper python-devels
> packages that pull in the proper pythonXX packages.

python23-devel, python24-devel.

> > > > * 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. [...]
> > >
> > > Isn't this only an issue when installing into non-versioned
> > > python dirs, which one should not do? :)
> > [...]
> > This piece has a good summary:
> > https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00
> >249.html
>
> Oh, now I see. Definitely no %ghosting would be my suggestion from a
> security and setup POV. Any package assuming it may write arbitrary
> non-fingerprinted code into /usr/lib deserves to be shot on sight.
>
> The package either needs bytecompilation/optimization, which has to
> be done at package creation time, or does not. Consider read-only
> mounted /usr or a tripwire checking /usr.

I never thought of it this way.  It's in wide use in fedora.us and=20
livna.org repos.  I'll bring it up over in Fedora to see what the=20
PowersThatBe think of it.  Now, I'm leaning against %ghost.

take care,
=2D-=20
=2Djeff