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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 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
