[PyVault-devel] Re: Packaging Python Pyvault Style (was Re: python
2.3 for RH7.3)
symbiont at berlios.de
Wed Dec 22 01:19:37 CET 2004
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.
3. The above scheme doesn't allow for multiple build areas python-devel
= 2.4.0 will upgrade python-devel = 2.3.4.
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).
> 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.
> python-devel could of course just be an intermediate stub for
> Yes, the latest rpm features of implicit Provides/Obsoletes are
> rather interesting ... :/
Well, this "interesting" feature throws out any possibility for creating
intermediate stubs. Play with Nasrat's provider spec yet? Make sure
you have plenty of -Uvh going on to see the interaction.
More information about the PyVault-devel