repotag in EPEL (was: Re: Plan for tomorrows (20070426) FESCO meeting)

[Jeff Spaleta]

On 4/26/07, Christopher Stone <chris.stone at gmail.com> wrote:
> Why is the repotag even considered part of the version string?
> repotags _should_ have nothing to do with version numbers as far as I
> understand it.

Historically, rpm's default cmdline query output doesn't provide
vendor identification information so its difficult for some users to
easily figure out where a package came from.
The rpm cmdline tool was never really designed with multiple package
vendors in mind. Its a problem.  Nor does yum's default status
information provide any vendor information for installed packages when
using yum list.  Certainly the add/remove gui makes no such effort to
inform you of the vendor for any installed package.  Even the rpmpkg
log that gets created nightly doesn't make any effort to inform local
admins about multiple vendors.

Repotags are a downstream effort to fix short-comings in status
information for the most common clientside package management tool
commands so that some repository originating information is relayed to
the poor unsuspecting and uninformed user/admin.  Repotags are duct
tape.

Something needs to be done to help users figure out where a package if
there is a problem... on their own. If they have to wander into an irc
channel or a web forum or mailinglist or bugzilla and be told how to
check the vendor string for packages.. so they can then go to the
correct irc channel or web forum or mailinglist or bugzilla ... that's
just wasteful and prone to the sins of misinformation (or the glory of
unpolitic truth depending on your pov).  These sort of repetitive
interactions with less technically skilled users strongly suggests the
usability of the clientside package management tools needs to enhanced
to be more robust to troubleshooting situations that involve multiple
repository package sets.

The reality is, its a lot easier to install new packages from 3rd
party repositories, then it is to go back and to identify which
package came from where..without a repotags.  Seriously, only perverse
masochists, like myself, go through the trouble reading the complete
manpage of rpm  and learning about the --qf option.  We certainly
shouldn't be expecting novice home system admins to know about --qf.
They really need a more accessible way to see the breakdown of their
installed packages by Vendor.

Even the Vendor tag isn't authoritative really.  The only way we can
generally solve this currently this is to rely on the actually package
signatures and relate those back to signing key ID strings (until
packages start using a more generalized cert istead of gpg sigs). And
there doesn't appear to be any way to do that with even an rpm
commandline argument with the rpm in fedora currently.  "Who signed
this package" is not a question that rpm can reasonably answer as far
as I can tell.  I wouldn't characterize an alpha-numeric key ID in the
-qi output as user-friendly.  I'd love to be able to ask that question
and get information like the output of rpm -q --qf "%{SUMMARY}\n"
gpg-pubkey-1ac70ce6-41bebeef.

You could of course go further and have repository information linked
to that particular key which repository aware client tools could use
to bring up contact information such as the bug tracker and
communication channels to be used for any package.

Just remember there is an underlying usability problem that goes past
the surface politics which repotags try to impact.  In the grubby
unpure everyday user world of multiple repositories, when problems or
bugs show up, how do those users interact with their computer system
so that they can be pointed to the best location for assistance for
the application they are having problems with?  If repotags aren't a
sound technical answer, then what is? And more importantly who is
going to step up to the plate and implement it?.

-jef"not me"spaleta

-jef