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

[Jeff Pitman]

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 ">=".

To make it so that system-config-*, and others, don't get removed.  To 
also allow for python23 or python24 to replace python without affecting 
other packages currently in the system.  It's the implicit requires 
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 
python rpm happens to Provide: python-abi = X.Y, then whatever I have 
as modules should be good to go.  Building the SRPM will be difficult, 
as that currently BuildRequires: python23-devel.  So, as of now, the 
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 
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?  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. [...]
> > >
> > > 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 
livna.org repos.  I'll bring it up over in Fedora to see what the 
PowersThatBe think of it.  Now, I'm leaning against %ghost.

take care,
-- 
-jeff