[repo-coord] Re: Noarch Naming Scheme

[Jeff Pitman]

On Tuesday 31 August 2004 16:07, Axel Thimm wrote:
> On Tue, Aug 31, 2004 at 08:00:58AM +0800, Jeff Pitman wrote:
> > My noarch packages will work on all distributions, I will be
> > dropping the DISTTAG.
>
> Are you sure python3 or something else in the future will still be
> compatible with the same modules? What happens when/if
> arch-independent stuff moves to /usr/share etc.

Python is really good at backwards compatibility in the API.  BUT, I 
said Distributions, not Python versions.  Distributions == rh7.3, rh9, 
fc1, fc2, suse9.1.  These guys will all have PyVault's Python.  So, I'm 
not running the assumption that I fling 1 package out randomly and it 
automatically works on all Distributions.  I know this is not the 
case .. remember the assumption: the core Python packages are uniform 
everywhere.  Now, it's just a matter of building up the add-on packages 
that enhance the Python libraries--and, along with that, a sane 
versioning scheme that allows for fc2 -> fc3 upgrades.  Though, I 
should be thinking about a sane py2.3 -> py2.4 scheme too!! ;)

> > But, the REPOTAG doesn't make sense by itself either.
>
> Why? You can use
>
> foo-works-on-every-distro-1.2.3-4.myrepo.noarch.rpm
>
> The repotag is only for identifying the package's origin. As such it
> is also rather optional, of course.

Ok.

> > So, currently, I just have a plain noarch there.  From an apt/yum
> > perspective, the repository is "Python 2.3" instead of "Fedora Core
> > 2" or whatever.  So, I could possibly use a DISTTAG of "py2.3" or
> > something.
> >
> > What are your thoughts on what should be done here?
>
> The latter sounds very good, but there may be a problem for python
> package linking against glibc etc. Suddenly you get dependencies to
> the underlying distro. So the above would work for noarch, but not
> for non-noarch and then you get multiple naming schemes. And worse of
> all, what happens when a packages starts up noarch and then gets some
> C written optimizations and needs to be renamed from "py2.3" to
> "rhfc3" (that would work by luck, but you get the idea)?

So, maybe I use non-versioned Epoch on Arch sets and a hacked versioned 
Epoch on Noarch sets.  I would never propose py2.3 for Arch packages, 
hence the Subject "Noarch Naming Scheme", because of the 
glibc/openssl/blah/blah linkage issues.

You're right about the migration of noarch -> i386.  I began addressing 
that in my response to Dag.

> But if you know that you will be supporting only the latest possible
> python with some package, so that you don't get to compare packages
> with the same buildid but different python builds, you can skip the
> disttag altogether. The disttag's main purpose is to ensure proper
> upgrade paths for concurrent builds.

Well, when I migrate to python2.4, having a py2.3 -> py2.4 transitive 
munge would allow me to mass migrate without incrementing the SPEC 
Release tag.  

We need to keep building on this discussion a little bit more.  Thanks 
for your input!

take care,
-- 
-jeff