[repo-coord] Noarch Naming Scheme

[Dag Wieers]

On Tue, 31 Aug 2004, Jeff Pitman wrote:

> On Tuesday 31 August 2004 08:29, Dag Wieers wrote:
>
> > 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.

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.

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.


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

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]