[repo-coord] Re: Noarch Naming Scheme
symbiont at berlios.de
Tue Aug 31 10:29:20 CEST 2004
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
> The repotag is only for identifying the package's origin. As such it
> is also rather optional, of course.
> > 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
We need to keep building on this discussion a little bit more. Thanks
for your input!
More information about the repo-coord