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

--===============0129945329000526073==
Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw"


--5G06lTa6Jq83wMTw
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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)?
>=20
> Ahhh!  The *invisible* obsoletes, of course!!
>=20
> http://distro2.conectiva.com.br/pipermail/apt-rpm/2004-August/002513.html
> http://lists.atrpms.net/pipermail/repo-coord/2004-August/000357.html
>=20
> 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

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

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

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

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

> > > * Do we really %ghost *.pyo? =A0That's what I'm doing now as an
> > > experiment discussed over at fedora.us. =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? :)
>=20
> 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.
>=20
> This piece has a good summary:
> https://www.redhat.com/archives/fedora-devel-list/2004-August/msg00249.ht=
ml

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.
--=20
Axel.Thimm at ATrpms.net

--5G06lTa6Jq83wMTw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBxxw6QBVS1GOamfERAtP/AKCVxoIgN2dDgvKzpSQyBoWC1XNIiACdHzvY
xQIdPBF5+eQcltpDvnJqyYM=
=HOxq
-----END PGP SIGNATURE-----

--5G06lTa6Jq83wMTw--


--===============0129945329000526073==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
repo-coord mailing list
[email protected]
http://lists.atrpms.net/mailman/listinfo/repo-coord

--===============0129945329000526073==--