[repo-coord] Re: Packaging Python Pyvault Style (was Re: python 2.3
Axel.Thimm at atrpms.net
Wed Dec 22 02:56:56 CET 2004
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.,
> 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
> 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
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20041222/91231a1b/attachment-0001.bin
More information about the repo-coord