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.
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
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.
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.
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.
Nice to see something constructive to solve the real problems.
Tim