On 8/21/07, seth vidal <skvidal(a)fedoraproject.org> 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(a)redhat.com> wrote:
> > >
> > >
> > > - Note that "default in mainline Fedora" doesn't
> > > 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,
> > 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
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
[ The above obviously neglects the type of question like "installing
this package is going to result in installing OpenOffice.org
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
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.