On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)

[Alexandre Oliva]

On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

>> My actual preference would be to instead use:
>> 
>> 0.<distid><distversion><repotag_opt><buildid>

> Buildid at the least significant position?

Doh, that was stupid, sorry.  I keep forgetting the reason why it has
to go before distid.  Anyhow, I'd still strongly suggest it to start
with for packages that are not in the Core.  Use 0.<count> for
<buildid> if you must, but don't start with 1 or higher unless you
actually mean to update a package with such a buildid from the Core
(or elsewhere).

> In general I don't see what purpose Alternatives would have.

I can only speak for myself, but the reason I'd like to have separate
Alternatives would be to enable myself to keep a rawhide install plus
add-ons, such that, if some package from rawhide fails, I know the
problem is in rawhide, not in an external repository that accidentally
or intentionally brought in a different version of a library, program,
whatever.  I realize kernel modules are a trickier issue, but on a
system meant to QA rawhide I wouldn't install them.

Another reason is that most repos lag behind rawhide.  Just to give an
example of one of my favorite pet peeves (without any offense to Dag
intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than
that of rawhide, even though his build is not actually more recent.
However, when I run up2date -u, it won't ugprade because of epiphany's
dependency on rawhide's mozilla, while dag's epiphany looks older than
that in rawhide so up2date won't use it.

Sure enough, if the epoch wasn't higher than that of rawhide, I
wouldn't run into this problem.  It would be lovely if this could be
fixed somehow, but there's no way for dag to downgrade the epoch
without breaking his <= FC1 repos, and blizzard didn't think this was
enough of a reason to bump up rawhide's mozilla epoch.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}