[repo-coord] Noarch Naming Scheme

[Jeff Pitman]

On Tuesday 31 August 2004 17:14, Dag Wieers wrote:
> On Tue, 31 Aug 2004, Jeff Pitman wrote:
> > On Tuesday 31 August 2004 08:29, Dag Wieers wrote:
> > 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.
>
> I'm not concerned so much about that. I'm concerned about using newer
> modules with older pythons or older modules with newer pythons. The
> main reason to put the modules in a versioned directory is to prevent
> that users are using modules that were build for some other version
> of python.

Nah. I'm not concerned about that.  90% of the reason older Pythons 
exist in PyVault is for compat reasons.  The other 10% is for potential 
testbed work developing on a very new distro release and targeting for 
a wider Python release target (eg. Python 2.2).

> The only way I can see it work is that your python module packages
> contain the modules for several versions in one package. Because
> changing the default python module pah to something unversioned may
> probably lead to problems that are out of control.

Yeah, I thought about this.  But, it's something I really don't want to 
mess with.  The basic rules are:

1) Every distro has the same core Python packages,
2) Add-ons are built for the latest Python release

The true "usefullness" of a Noarch package within the realm of PyVault 
itself is I can have 1 directory that is installable on all Distros 
(who have Python 2.3.4 installed from PyVault).  This is *not* to say I 
have 1 directory that is installable on all Python releases (eg. 1.5.2, 
2.2.3, 2.3.4).  I think this is where you and I are differing in 
understanding.  My focus is that a user uses PyVault for *both* the 
Python package and the add-on packages.  I'm not focusing on package 
usefullness outside of the realm of Pyvault.

> > 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!
>
> Well, in the case you describe you have to remember to increase the
> release too. Something you should do anyway if you make changes.
> And the release get precedence anyway.

Uhm, my SPECs are common for all distros.  If I change a Spec, the 
release increments, then all of the distros will increment along with 
it.  I'm not planning on individually tracking the different releases 
for different distros.  So, the DISTTAG ordering is still important.

take care,
-- 
-jeff