Re: Package Management Blows Goats (use cases)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard Hughes <hughsient@xxxxxxxxx> wrote:
> (from my blog, apologies to anyone that's read this once already)
> 
> Before ideal system requirements we should talk about use cases and
> system interactions. I think this is where update systems have gone
> wrong in the past, closely integrating with the existing package system
> rather than studying the complete ideal user interactions.
> 
> Feel free to disagree and correct the interactions.
> 
> Boot Time Security Update
> 
> Toby logs into his desktop. A notification area icon with a critical
> icon appears in the top right and a libnotify popup tells him there are
> 3 three critical security updates. The libnotify popup has three
> buttons:
> • Update now in the background
> • Always do updates automatically
> • Ignore for now
> Toby clicks the first button and the update completes in the background.
> When completed, after a few minutes, another libnotify popup appears
> telling Toby that the update was completed and after a few seconds the
> status icon disappears.
> 
> Downloading an Unknown Application
> 
> Suzanne wants to open a word file. She opens the software finder tool
> and types "office file" into the search box. A list of software appears,
> with OpenOffice being the top entry. She clicks the OpenOffice entry to
> highlight it, and clicks "Install now". Suzanne is not an administrator,
> but because she is locally logged in and the package is from the "fedora
> GPG signed repository" the root password is not required. A notification
> area icon appears with a downloading icon and the package manager is
> closed. When OpenOffice is installed, a libnotify popup tells Suzanne
> that the software has been downloaded and is now ready to use.

What if they use a local mirror? What about extraoficial repos? What
about locally built packages?

What about computer labs (or other places) where "user installs random
software" is *not* wellcome? What about packages that require sysadmin
configuration (define local configuration, start server, ...)?

> Installing files automatically
> 
> Simon wants to borrow the computer while Suzanne waits for OpenOffice to
> download. He uses fast-user switching to switch to a new login. He
> notices the same downloading icon in his session which indicates
> Suzannes' download is still in progress. He starts Pidgin which then
> crashes. The bug-buddy window appears which prompts him to install the
> debuginfo so a valid backtrace can be detected. He clicks yes, and a
> libnotify windows appears telling Simon that the request has been queued
> and that he will be notified when the debuginfo has been installed. When
> installed, the bug-buddy helper continues and submits a valid bug.

This is /not/ "installing automatically", it is another user installing
new stuff while another install is running. Now you need to distinguish
between users that are allowed to install stuff and those that aren't
allowed to do so.

A similar case is that Suzanne gets bored waiting for OOo, and asks for
a (smallish) game to kill time.

Again, what about situations where installing random stuff should not be
allowed?

How about getting rid of Joe R. User installed stuff later on (might be
required for "cleanup" or whatever)? At least a indication of who
installed what is needed.

> Installing new features
> 
> Suzanne switches back to her session and wants to add some clipart to
> the word file she has just opened. She clicks "Insert" and then
> "Clipart" and then a windows pops up telling her that clipart is not
> installed. She clicks "Install" and a progress bar appears and moves
> across as the clipart is downloaded and then installs. When finished,
> the dialog disappears and she chooses a picture of a cat.

> Comments?

All the above presuposes a /huge/ bandwidth to the 'net (or at least to
a nearby mirror). Plus nearly unlimited disk space (yes, the sum total
of what the users will end up installing by just random twiddling /is/
everything). Not my case, unfortuntely. And I suspect that is the case
of lots of Fedora users.

As a end user, this is fine (but then, the end user owning the machine
has the root password and knows how to use it); as the sysadmin of a
bunch of machines (that I want to keep with reasonably {c,}lean
configurations, at least for security reasons) this is one of the very
first things I'd completely disable.

sudo + a configuration that allows running "yum install foo" or "yumex"
for assorted users is almost enough for all of the above, plus gives
some extra control. I don't see a burning need for any of this, to tell
the truth.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux