repotags proposal
Tim Lauridsen
tla at rasmil.dk
Wed May 23 07:35:10 UTC 2007
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
More information about the epel-devel-list
mailing list