On Wed, 2007-08-22 at 10:18 -0400, Owen Taylor wrote: > On 8/21/07, seth vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote: > > > On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote: > > > > On 8/21/07, David Zeuthen <davidz@xxxxxxxxxx> wrote: > > > > > > > > > > > > - Note that "default in mainline Fedora" doesn't preclude the > > > > desktop > > > > spin from using PackageKit instead of Pirut. > > > > > > > > Hmm. That seems like a really big change to be making from mainline > > > > in a spin. I think a good goal for spin changes is to think hard > > > > about putting in changes that we do want to go down into the OS in > > > > general. > > > > > > Hey, let's not get carried away; this is not a OS-level change, it's, in > > > effect, simply just another UI frontend for yum, not much different from > > > pirut/pup, yumex, whatever except that it's designed to solve the > > > problem in a much nicer way (at least some of us think) both from a > > > technical point and an user experience point of view. There's no reason > > > to fear change. > > > > > > > >From a technical point it doesn't solve the problem in a different way > > at all. I've been helping Richard with scripts to backend packagekit > > with yum and the scripts are extremely simple. To be clear - some of the > > user experience items are really just papering over the security > > questions and hoping no one notices that right now PackageKit is the > > equivalent of: > > > > yum -y do_whatever_just_be_quiet_about_it. > > I have a *strong* opinion here that it's *never*, *ever* right to ask > the user a question when installing or removing a package. A question > is going to be of the form: > > A) This operation may trash your system [detail that the user doesn't > understand removed]. Proceed? > > B) The package that you are installing might be created by an evil > haxor and do bad things [details that the user doesn't understand > removed]. Proceed? > > The user has no basis on which to make the decisions, and all you've > done is created some coverage for yourself when they continue anyways > and bad things happen. And when I say "the user doesn't understand", > I'm not being dismissive of some imaginary naive, clueless user. *I* > almost never understand the details in such cases. > > I do think it's important for something like PackageKit to return > maximally descriptive error messages to the user; I was quite > concerned when I saw Richard post that everything had to be turned > into an error enum in PackageKit so that the translation could be done > in the front end. I think that's just wrong, and you always want error > message *strings* to be part of the system, translated at the source > when applicable. > > [ The above obviously neglects the type of question like "installing > this package is going to result in installing OpenOffice.org, and > downloading 300megs of extra packages, taking 3 hours, proceed? Which > is legitimate to ask the user. I think that type of question, is, > however, generic enough to be part of a system like PackageKit ] I'm a little bothered that you're picking and choosing which questions you think users can answer. I think users can intelligibly understand statements about gpg keys. The difference here is that I'm assuming that users are smarter and/or capable of using google to understand what's going on. I know this is a cliche - but if you assume your users are stupid, then you end up with stupid users. Now, for a lot of yum questions we don't assume the user is stupid, we assume the user is not present. (ie: unattended cron or daemon-drive runs). I understand the virtue of making the defaults make sense. I also understand the virtue of not showing up on bugtraq b/c you auto-import gpg keys w/o so much as a notice about it. -sv -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
