[repo-coord] Noarch Naming Scheme

[Jeff Pitman]

On Tuesday 31 August 2004 08:29, Dag Wieers wrote:
> On Tue, 31 Aug 2004, Jeff Pitman wrote:
> > What are your thoughts on what should be done here?
>
> Well, I'm curious to how you can be sure the python-modules are not
> python-dependant. (And what the mechanism is for loading these
> modules when they are placed where they are placed :))

Pretty easy: I provide the Python.  This Python works identically on all 
distributions.  When I move to Python 2.4, then I cut another 
python/2.4/noarch section rebuilding the noarchs there.  So, the 
modules are still placed in /usr/lib/python?.?/site-packages, but the 
upgrade paths are dependent on PyVault's core packages and not on the 
distro.  So, basing the noarch packages on a distro is a bit of a 
misnomer.

> Furthermore, if the place is not the default one, what about having
> the same modules installed that have a different naming-scheme
> applied. You could be using another module than you think you're
> using.

Yes, interoperation has to be taken care of.

> So, although I can understand people wanting a newer python on an
> older system, or an older python on a newer system in specific cases.
> I don't think generic python modules serve the general cause very
> well.

I understand completely.  But, these python modules are built for use in 
one environment: someone using PyVault.  If one wants to download the 
srpm and rebuild for another environment, then that's cool too.

> We're basicly using it for huge packages that contain data like
> themes, moviepacks and other generic datafiles. Or for binary-only
> packages that have no other tweaks than the binaries they ship. It
> can only be applied of course if they work for _all_ the
> distributions, if there's one exception the deal is off.

With pure Python modules, the deal will always be on--using noarch for 
the Arch.  If there's any extension modules or C-written speedups, then 
the deal is off.  At this point, I'd use i386 for Arch.

The "0" for disttag could be a problem for the case where a package goes 
from noarch status to i386 status because the upstream package 
optimized some of their code in C.  Using an epoched disttag, I would 
get something like this:

0.rh73 < 0.rh9 < 0.pyv < 1.fc1 < 1.fc2

But, I guess it works for non-epoched with "rh" munge:

0.pyv < rh73 < rh9 < rhfc1 < rhfc2

Argh! 


take care,
-- 
-jeff