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

--===============3631048779176988355==
Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="1Sa0i77dkqaUxqYg"


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

On Wed, Dec 22, 2004 at 08:19:37AM +0800, Jeff Pitman wrote:
> On Wednesday 22 December 2004 06:03, Axel Thimm wrote:
> > On Wed, Dec 22, 2004 at 12:16:20AM +0800, Jeff Pitman wrote:
> > > On Tuesday 21 December 2004 02:38, Axel Thimm wrote:
> > > > Only python developers need to take care to have proper
> > > > python-devels packages that pull in the proper pythonXX packages.
> > >
> > > python23-devel, python24-devel.
> >
> > I'd prefer python-devel-2.3.4-xxx, python-devel-2.4.0-xxx. The reason
> > is that python packages (modules and apps, not python itself) should
> > have a plain
> >
> > BuildRequires: python-devel >=3D 2.2
> >
> > Otherwise you end up rewriting specfiles for rebuilding packages on
> > different pythons.
>=20
> I agree, except:
>=20
> 1. The package has a prefix of pythonXY in some instances. (eg.,=20
> python23-twisted)
> 2. The package puts files into /usr/lib/python2.3/site-packages anyway.

Can't this be (automatically) taken care of by macros and/or asking
python/sys etc.?

> 3. The above scheme doesn't allow for multiple build areas python-devel=
=20
> =3D 2.4.0 will upgrade python-devel =3D 2.3.4.

Yes, that was the comment on PyVaultians needing to have a clever
buildsystem like say a pythonXX chroot for each pythonXX.

> 4. If the above version *is* in the name, then that means BuildRequires=
=20
> should have that as part of the string or it won't compare the right=20
> package. (unless I'm missing a neat feature of rpm).

Don't understand this, which BuildRequires are you thinking of?

> > Python package developers (PyVaultians? ;) need to take care to have
> > a build-system that allows picking the right python-devel out of
> > multiple. ypt/yum will always pull in the latest, which will be the
> > right choice for most applications.
>=20
> Maybe.  Need a more concrete example.  Current version is based on the=20
> principal: "explicit is better than implicit".  Only package developers=
=20
> are going to care, really.

Indeed. If it creates more issues than it solves, dump it :)

> > Yes, the latest rpm features of implicit Provides/Obsoletes are
> > rather interesting ... :/
>=20
> Well, this "interesting" feature throws out any possibility for creating=
=20
> intermediate stubs.

It throws out concurrent package existance in general. :(

> Play with Nasrat's provider spec yet?  Make sure you have plenty of
> -Uvh going on to see the interaction.

I'm aware of the ugly rpm bug^Wfeature "all Provides are automatically
obsoleting packages/Provides of the same name". Does Paul Nasrat's
example demonstrate any further rpm regression?

It's good to have someone inside of RH that understands there is a
problem with the Provides/Obsoletes schema, let's hope it will create
a solution ... :/
--=20
Axel.Thimm at ATrpms.net

--1Sa0i77dkqaUxqYg
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFByNRoQBVS1GOamfERAtSCAJ9BHnA5gMGuTh77Un+vRbUVWXgyHACdEMvN
1Vt0mqxfw0wcXRNRogXk5RI=
=HCwQ
-----END PGP SIGNATURE-----

--1Sa0i77dkqaUxqYg--


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

--===============3631048779176988355==--