Fedora Project launches Pre-Extras

Dag Wieers dag at wieers.com
Sat Dec 18 22:36:58 UTC 2004


On Sat, 18 Dec 2004, Michael Schwendt wrote:

> On Sat, 18 Dec 2004 22:58:40 +0100 (CET), Dag Wieers wrote:
> 
> -snip-
>  
> > Which is why I considered .fdr. for fedora.us as a bad choice for a 
> > repotag.
> 
> Really? Is that documented anywhere? The repository was named "Fedora
> Linux" and the first to use the name "Fedora", so .fdr as a repo tag
> was very obvious. Just like .fr for freshrpms.net or .dag for your
> packages.
>
> When a fan of your repository would offer compatible packages and mark
> them with .dag in the filename, it would not be any different than if
> other repositories use the .fdr tag started by fedora.us.

Correct, but using the same tag when Red Hat adopted the Fedora brand was 
asking for trouble IMO. Other repositories using the same name is clearly 
against some of the advantages and if this would happen to me (and I knew 
about it) I would talk to the other repository and explain why it is 
confusing. For something generic as .fdr. it may be harder to make your 
point. That's why I considered it a bad choice. 

I don't think it's a very good choice by the other repositories that used 
it. Probably explaining people what the repotag is for would have avoided 
the .fdr. confusing in the first place.


> > > The same applies to distribution tags. As long as '.FC3' and friends
> > > are not too common, they stand out when you look at a package name.
> > > As soon as many other packagers use the same dist tags, they don't
> > > add anything other than influencing RPM version comparison.
> > 
> > How does it influence the RPM version comparison in a relevant way ?
> 
> Well, it doesn't make much sense to discuss this further or to pound
> on obvious examples. Since for inter-repository dependencies, I'm an
> advocate of the "determine overlapping contents and move them into a
> common base repository" methodology. Alternatively, replicating common
> packages with exactly the same NEVR (and preferably, built in the same
> environment) would be another solution.

Please give me an example where it influences the RPM version comparison 
in a *relevant* way ? You, Seth and Jeff are spreading this fable and it 
is the only argument I heard to get rid of it.

All the obvious examples are broken, even without repotag or disttag there 
is no important reason why release 2 from one repo should be upgrade to 
release 3 of another repo.

That's the essence, and everything else is BS. Sorry.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]




More information about the fedora-test-list mailing list