[repo-coord] Re: Noarch Naming Scheme

[Axel Thimm]

Hi Jeff,

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.

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

> 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)?

There are only very few distro-independent packages like firmware,
fonts or skins.

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.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040831/57ea9a3b/attachment.bin