On Sun, Mar 18, 2007 at 08:33:44PM +0100, Michael Schwendt wrote:
Why would a __user__ want a repotag? All the users want is that
repositories "just work" when they are enabled and installed from, even if
it is an unusual mix of repositories.
That way you could argue that a user doesn't need a release tag as
well, right?
A repotag does not contribute anything to achieving that. If the
repotag is abused for RPM version comparison (as the
least-significant part of %release), so packages from one repo
upgrade packages from another repo, that would be really bad.
Does any repo do that? I think not. Running a repo with the "lowest"
repotag I can assure you that repotags are not abused in the way you
imagine them to be.
Similarly bad is it when repositories compete with eachother in what
they contain and when that leads to incompatibilities.
That has nothing to do with a repotag, ...
A repotag only attempts at pushing some of the dirt under the
carpet.
... which is why a repotag cannot improve this situation. A repotag is
simply for a quick identification of a packge, be it in a simple rpm
-qa list or as a package filename. That's all there is to it, it's not
a magical compatibility layer.
FWIW I would like to be able to distinguish RHEL packages from EPEL by
a simple glance. Given RHEL's structure in several layered products I
can never be sure whether it's RHEL, RHCS, RHGFS, RHAPPS already. At
least when I see an "at", "rf", "centos", "sl",
"kde" as a repotag I
know it's none of the official stack.
So it's not only distinguishing 3rd party repos, it's for
distinguishing from the base os, too.
And it's a matter of cooperation: Do we want EPEL to cooperate with
existing 3rd party repos, or do we want EPEL to not do so and create a
new rift? It's so much more a political issue than a technical one.
--
Axel.Thimm at
ATrpms.net