Re: repotags proposal

[Tim Lauridsen <tla rasmil dk>]

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