skvidal at linux.duke.edu
Wed Oct 18 22:38:09 UTC 2006
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.
you phrased very well the reason why I closed the bug.
More information about the Fedora-maintainers