On May 12, 2004, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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}
