repotags proposal

[Panu Matilainen]

On Sun, 20 May 2007, Thorsten Leemhuis wrote:

> I wrote a quick proposal for repotags in EPEL. If people really want
> repotags in EPEL please speak up in this thread -- I'd really like to
> see that contributors really want repotags before I propose this
> proposal for voting in a SIG meeting.
[...]
> That agreement if given for EL4 and EL5 only -- the EPEL Steering
> Committee would like to see a technical solution that properly solves
> the problem repotags are trying to solve currently.

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?

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

 	- Panu -