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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
