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

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.
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
> pythonXX-devel.
>
> 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.

take care,
-- 
-jeff