Dropping the repotag

[Michael Schwendt]

On Sun, 18 Mar 2007 23:54:21 +0100, Axel Thimm wrote:

> %dist bad? How come?

It has been beaten to death in past discussions with several real-world
examples.

> It gives us nice upgrade paths w/o juggling
> through several *different* specfiles per distro 

That's a myth. It breaks already when somebody creates CD/DVD snapshots of
the distribution and performs a dist upgrade. That is because many
packagers bump %version and %release way too often and in ways that
strictly depend on a rolling-release with online updates. %dist cannot fix
that. To fix the upgrade path, it would need a dist epoch, that is
separate from ordinary RPM version comparison.

> just for the sake of
> human-controlled and human-error-prone housekeeping.

*lol* How some packagers rely on %dist when copying a spec from devel to
older branches, creates nothing else than chaos.

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

It's a good example of a pitfall.

A package is from Livna, when it is signed with Livna's key, not
necessarily when it has "lvn" somewhere in the file name. Users all around
the world have been fooled by that before in the same way they've been
fooled by other tags.

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

It is long ago since we've talked about forms of cooperation and
collaboration for the first time.

Yet it is still not carved into stone anywhere as what cooperation exists
actually.

Assume libfoo is offered by EPEL *and* a 3rd party repository. The repotag
flags the package as coming from the 3rd party. A user is fully aware of
the repotag and submits a bug report to the 3rd party.

Where is the benefit of polluting %release (which influences RPM version
comparison) and file names with more values, that ought not be part of the
package release? Is it still only that the EPEL packager needs to find out
about any 3rd party package that might be "out there" and lurk in bug
reporting channels to learn about problems that affect compatibility with
EPEL or affect EPEL, too? Has anything been done on making actual
cooperation become reality?