[repo-coord] Noarch Naming Scheme
symbiont at berlios.de
Tue Aug 31 10:34:29 CEST 2004
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
> 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
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
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
More information about the repo-coord