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

[Axel Thimm]

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 >= 2.2
> >
> > Otherwise you end up rewriting specfiles for rebuilding packages on
> > different pythons.
> 
> I agree, except:
> 
> 1. The package has a prefix of pythonXY in some instances. (eg., 
> 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 
> = 2.4.0 will upgrade python-devel = 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 
> should have that as part of the string or it won't compare the right 
> 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.
> 
> Maybe.  Need a more concrete example.  Current version is based on the 
> principal: "explicit is better than implicit".  Only package developers 
> 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 ... :/
> 
> Well, this "interesting" feature throws out any possibility for creating 
> 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 ... :/
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20041222/91231a1b/attachment-0001.bin