yum RFE

[seth vidal]

On Wed, 2006-10-18 at 14:52 -0700, Toshio Kuratomi wrote:
> 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,
 you phrased very well the reason why I closed the bug.

Thank You,
-sv