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

--===============1478123890959513226==
Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="XvKFcGCOAo53UbWW"


--XvKFcGCOAo53UbWW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 20, 2004 at 02:56:41PM +0800, Jeff Pitman wrote:
> On Sunday 19 December 2004 20:01, Axel Thimm wrote:
> > I've been doing some thinking around this. How about the following
> > scheme, which is almost already what pyvault does:
> >
> > python15
> > [...]
> > python22
> > python23
> > python24
> >
> > are packages that don't conflict/overlap and also have no
> > alternatives/symlinks etc. Using python means calling it as python2.4
> > etc.
> >
> > All python module/app packages built should get their
> > "#! /usr/bin/python" replaced with the matching python version they
> > were built against. So every python package pulls in the right
> > pythonXX package and uses it independently of /usr/bin/python
> > settings.
> >
> > And then there are "python" packages that just setup the symlinks in
> > bin for the vendor and user (e.g. python on RH7.3 still points at 1.5
> > for compatibility's sake. These packages are not really needed for
> > pyvault package to work.
> >
> > python-devel package should always point to the latest available
> > python in pyvault. That ensures that you can always use
> > "BuildRequires: python-devel >=3D ..." w/o using any numbered python
> > (=3D> no specfile editing when rebuilding other than tags). For
> > packages (build)requiring an older python the explicit pythonXX-devel
> > tags can be used to lock it onto a python version.
> >
> > On the python module/app package versioning: I'd skip the python
> > version built against (just like perl and C do not include the perl
> > or glibc version against their were built) and use natural names.
> > After all when pyvault supports a new python on all distributions,
> > all package will be built against it, and the few that need fixing
> > will just depend on a slightly older python.
> >
> > I.e. the use model assumes that the pyvault maintainer and
> > packager(s) test a new python version, approve it for becoming the
> > next base version and rebuild everything against it. pyvault also
> > provides the compatibility packages for other python packages not
> > included in pyvault (like the vendor's), and also some python
> > packages that won't build against the latest approved python version.
> >
> > It is also more maintainer friendly (i.e. don't support package pyfoo
> > on multiple different python version, only one one).
> >
> > Does that model sound OK for you?

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

> But, the gist of it is to make available a set of packages that=20
> maintains compatibility with existing python packages without impacting=
=20
> 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 rebuild applications to
burn in the python version (like "#! /usr/bin/python2.2"). Here is a
macro for that purpose:

%python_burninversion find . -type f | grep -l "^#!.*python" | xargs perl -=
pi -e's,^(#!.*python)([^0-9.]*|$),${1}%python_version$2,'

> I'd like to use natural names where possible, but the RPM issue with=20
> Obsoletes still lurks.  Providing unique package names with the=20
> versioned Python inside of it is the only way to prevent this. =20

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?

> * Do we really %ghost *.pyo?  That's what I'm doing now as an experiment=
=20
> discussed over at fedora.us.  I'm not sure if Extras will have this=20
> policy or not.
> * Need to re-bytecompile applications for the latest version of python.=
=20
> (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? :)

We aren't ghosting /urs/lib/lib*.so.* either with sources autobuilding
when a new glibs/gcc is installed :)
--=20
Axel.Thimm at ATrpms.net

--XvKFcGCOAo53UbWW
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBxrPAQBVS1GOamfERAizhAJ4xWxly/sP+SRFNlXswGxWXq/Gi4ACfUVUZ
ALqEtf3h8svJ980Ob2Umsb4=
=m+wS
-----END PGP SIGNATURE-----

--XvKFcGCOAo53UbWW--


--===============1478123890959513226==
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

--===============1478123890959513226==--