Dropping the repotag

Michael Schwendt mschwendt.tmp0701.nospam at arcor.de
Sun Mar 18 22:26:50 UTC 2007


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.

The release tag in the file name makes it possible to place multiple
releases of a package in the same directory. Where that is unnecessary,
naming packages %{name}.rpm would be enough.

Same applies to %version, %arch, and %epoch (oops, it isn't part
of the standard package file name).

All the interesting values can be retrieved from the package headers.

> > 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.

> > 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.

> > 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.

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.
 
> 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.

> 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.

> 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?




More information about the epel-devel-list mailing list