yum RFE

[Toshio Kuratomi]

On Wed, 2006-10-18 at 12:38 -0500, Josh Boyer wrote:
> On Wed, 2006-10-18 at 13:15 -0400, Greg DeKoenigsberg wrote:
> > I am reluctantly in Mr. Stone's camp here.
> > 
> > Reluctantly, because the strident nature of the evolution of this thread 
> > has obscured what I find to be a real issue: the question of what is and 
> > isn't "blessed" in the universe of Fedora packages.
> > 
> > There are *a lot* of people don't quite understand how packages work -- 
> > and they certainly don't understand the ramifications of using a repo that 
> > overwrites packages from Core.
> > 
> > I don't think it's unreasonable to package this plugin.  I don't even 
> > think it's unreasonable to enable it by default; I certainly think it's a 
> > potentially worthwhile discussion.
> > 
> > Is it a sensible compromise to include this plug-in by default for now?
> 
> I think it's sensible to include the plugin in the Fedora package.
> Whether it should be enabled by default or not... dunno.

It's sensible to include the plugin to aid intermediate and advanced
users in mixing repositories.  But only with default off.  If you read
Mr Spaleta and Mr Vidal's notes in the bugzilla RFE, you'll see that
default on has a variety of drawbacks.  And I'll go further to say that
this plugin (default on or default off) doesn't help the novice level
user who is the theoretical beneficiary of this change.

The end goal, as far as the novice user is concerned, is to install a
piece of software and be able to use it on their system.  If that
package drags in some Core overriding packages that break their system,
they aren't getting what they want.  If that package is prevented from
installing because it drags in some Core overriding packages that won't
break their system, they aren't getting what they want.

We provide a Linux Distribution.  Users and third party developers are
free to do with it as they please.  Instead of trying to protect users
from themselves (something that's doomed to fail -- people are clever
enough to outsmart any roadblocks we put in place even if they don't
understand why those roadblocks were there in the first place) we need
to work with the greater community of packagers to diagnose why things
are failing and get them fixed.

Let's look at this from another angle:  If a new user installs Fedora
and finds a bug in our KDE packages which prevent people from logging in
with KDE as their session, do we tell them to uninstall KDE and use
GNOME instead?  No, we tell them to report it as a bug.  And if they
need to login immediately and there aren't any KDE devels available to
help diagnose the issue we may tell them that using GNOME is a
workaround until the bug is fixed.  Similarly for problems traceable to
ATRpms, we should let the user know that ATRpms would like to know about
bugs in their packages so they can fix them.  And if no one from ATRpms
is able to help them diagnose the issue right now we can help them back
out the ATRpms packages as a temporary workaround.

Should we do this even though ATRpms isn't part of the Fedora Project?
Yes, we should.  ATRpms is providing a service for our users.  It may
not work perfectly all the time but it is doing something that we are
unable to do ourselves *that our users want*.  Axel is willing to work
to get issues resolved, both by fixing bugs in his packages and by
trying to get changes merged into Fedora packages so he doesn't have to
carry the modifications.  Instead of worrying about ways to prevent
ATRpms packages from getting onto our user's systems (something that our
user's *want* to do) we need to take two steps: 1) Report bugs to Axel
when they occur in his packages. 2) Help Axel to get his changes merged
into Fedora Core.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20061018/e56c41a4/attachment.sig>