Dropping the repotag

Axel Thimm Axel.Thimm at ATrpms.net
Sun Mar 18 22:54:21 UTC 2007


On Sun, Mar 18, 2007 at 11:26:50PM +0100, Michael Schwendt wrote:
> On Sun, 18 Mar 2007 22:55:11 +0100, Axel Thimm 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?
> 
> ???
> 
> No, not right.

Well, you didn't get it, so let me exaggerate to make my point: A user
doesn't even need a version, he doesn't need anything as long as
everything works, not even the output of rpm -qa.

Residing on the non-errant part is not a problem, the issue is what
happens if someone needs to take a closer look?

> > > 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.
> 
> This is not about imaginations, but about mixing repositories that offer
> overlapping or incompatible contents. Again, the same old story.

Which has nothing to do with repotags.

> > > 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, ...
> 
> Still the repotag would be part of %release, which is bad for the
> same reasons as %dist is bad.

%dist bad? How come? It gives us nice upgrade paths w/o juggling
through several *different* specfiles per distro just for the sake of
human-controlled and human-error-prone housekeeping.

> > 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.
> 
> Quick, maybe, but error-prone, as independent packagers already use %dist
> in the same way Fedora and Livna do. And Livna's tag is a two-in-one
> repo+dist tag.

I'm not sure if you mena that as a praise or blame. There is nothing
wrong with livna's tagging. It is indeed a shortened and otherwise
unusual disttag/repotag, but it fully serves its cause.

> > FWIW I would like to be able to distinguish RHEL packages from EPEL by
> > a simple glance.
> 
> Installed packages, I guess. Then query the RPM database or metadata
> with the proper options.

Where's the "simple glance" in that?
 
> > So it's not only distinguishing 3rd party repos, it's for
> > distinguishing from the base os, too.
> 
> And still users will file bug reports about the wrong component as
> long as no tools aid them in collecting good details.

Then provide them the tools as well. The repotag certainly doesn't
discourage that.

> > 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.
> 
> I have no doubts that you think about cooperation as you've already joined
> the fun with Fedora Extras. That doesn't apply to other repositories,
> though. What cooperation is reality for Fedora Extras and Fedora Core, for
> instance? Are there guidelines? A SIG with close contact to 3rd party
> maintainers? A steady exchange of bug reports, fixes, testing results?

Why raise the bar that high? This is just making things more difficult
to accomplish. Maybe all this kind of cooperation needs small signs of
willingness to cooperate before a whole framework of sig, rules and
further procedures is put up?
-- 
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://listman.redhat.com/archives/epel-devel-list/attachments/20070318/7fd6021c/attachment.sig>


More information about the epel-devel-list mailing list