repotags proposal

[Dag Wieers]

On Wed, 23 May 2007, Tim Lauridsen wrote:

> Panu Matilainen wrote:
>
> > My 5c on the topic I've been trying to avoid because it's too flammable for
> > my taste. I hate politics so I'm not going to get into that, I'm commenting
> > from purely technical POV, and actually have a proposal that might make them
> > unnecessary.
> >
> > Repotags as part of release string are just plain wrong. Unlike disttag, the
> > repotag does not have a meaningful version information in it, it's really
> > just a fuzz-factor to somehow differentiate packages coming from different
> > places.

It does have meaningful version information in a multi-repository world. 
It shows what version of the package you have. rf means this is the 
RPMforge version. It makes the package/filename/version unique !

Granted, the repotag does not have any real meaning in "version 
comparison" between packages from different repositories. Neither does the 
release tag. The release tag has no meaningful version information between 
packages from different repositories.


> > The perfect repotag would actually be the package's gpg signature:
> > - it's not involved in version comparison
> > - it can't be faked by locally rebuilding a package - it's recorded in rpmdb
> > so it's possible to see where a package came from

It is not a perfect repotag for other reasons:
- It doesn't make the filename unique (or gives insight of the package 
  before downloading)
- It is not shown when one has dependency problems, either on yum, apt or 
  rpm level


> > For depsolvers, you need some sort of priorisation mechanism anyway to make
> > any sense out of mixed repository situation. So the repotag mostly serves as
> > a visual clue to humans. All the major depsolvers now have some means to
> > priorize between repositories so what the actual rpm EVR string is doesn't
> > really matter, what's missing is the visual clue.

The major depsolvers lack a meaningful way for a user to provide a policy 
of what they want to do with repositories or packages. Some plugins do 
allow somewhat more, but there are many shortcomings and without repotags 
errors are at first sight inexplicable or confusing.

Especially when packages from different repositories have the same NEVR, 
similar sub-packages and have dependencies between them.

The clamav package is a nice example. Without repotags, dependencies would 
exists between packages from different repositories.

Saying that repotags have no meaningful version information is very wrong. 
It makes the system work.


> > Now, I hereby volunteer to write a script/popt-alias/whatever that will do
> > the necessary mapping of gpg signature into something human readable so
> > people can diagnose their repo-mixing problems and whatnot easily. So you'd
> > get something resembling the below:
> >
> > $ repotag -q foo bar
> > foo-1.2-4.el5 (EPEL)
> > bar-2.3-1.el5 (ATrpms)
> >
> > Would something like that be enough for the "repotag folks", short term?
>
> Look like a great idea, do you plan to do at standalone tool or something
> based on the the Yum API, it sounds like a candidate to
> yum-utils.

It doesn't help for dependency problems. In this case it shows what a 
working rpmdb consists of. Necessary, but not sufficient to replace a 
repotag implementation as it is.


> > Long-term, more than that's needed to really solve the issues with
> > repository mixing. One (perhaps crazy) idea is turning repotags into
> > namespaces, and dependencies are first looked up within that namespace and
> > only if unsolved, other namespaces are looked at in (configurable) order.
> >
> > An example (please excuse the :: notation, that's not a good choice but for
> > examples sake...): assume we have packages foo and bar which both depend on
> > glibc, and foo additionally depends on bar. Foo and bar are available from,
> > say, both EPEL and ATrpms:
> >
> > rhel::libxml2-2.6.28-1
> > epel::foo-1.2-1
> > atrpms::foo-1.2-1
> > epel::bar-2.4-5
> > atrpms::bar-2.4-1
> >
> > If you install atrpms::foo, as atrpms namespace also provides bar, that one
> > gets selected instead of epel::bar even though it's evr is higher. The
> > actual namespace could internally be the gpg signature, only mapped to a
> > human readable where exposed to the user. Sound crazy enough? ;)
>
> Yes, i sounds very crazy to me ;-) ;-) .
> I dont know if this can be done without a lot of changes into RPM.

The namespace idea is an interesting one and when it gets implemented and 
is ready is surely an alternative to repotags.

But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we 
cannot consider it an alternative because we cannot use it now.

It's not that I'm unwilling to see an alternative, it's just that there is 
NO alternative to repotags that cover it's different uses.


> Nice to see something constructive to solve the real problems.

It doesn't solve real problems as it is not a realistic solution yet.

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