What happened to pup?

Jeff Spaleta jspaleta at gmail.com
Mon May 23 15:55:07 UTC 2005


On 5/22/05, Kyrre Ness Sjobak <kyrre at solution-forge.net> wrote:
> That is the job of a well-written web portal.

web portals are nice.. but surely a different website portal per
repository is an inherently redudant and complex way of accessing
information that should be available on the client computer via
metadata. I don't think relying on web portals is the best solution
long term. A client side application that reads metadata either from
repositories on the network or repositories defined locally is the
best primary way to 'find' packages.  Unless of course, you are
willing to jettison any hope of building a solution that allows people
to use repositories on local media and will require everyone to have
network access.

Fire up an install application, that allows for some ability to browse
the entire configured package catelog available on that client.

> Auch. That i did not think about. But surely, some solution could be
> found.

Isn't license review as part of 'finding' a package good enough?
I don't think license review is worth imposing on people as part of
the install step for the vast majority of software. For the small
percentage of proprietary software that exists for linux... provide a
post package install license review mechanism... if those restrictive
propretary eula's require a click-through before using the software.

> But more intuitive. Almost every user "discovers" up2date immediatly,
> and try to use that. They do not discover yum before someone points them
> to it.

And I say build something to replace up2date that is a client side app
instead of relying on browsers and multiple website trolling everytime
you want to find a package. If up2date is a poor implementation of an
intuitive approach..then i say we re-implement that client side
application approach.. instead of moving to a website portal download
approach.

> Also a good idea - but what about libs, such as gstreamer-mp3? BTW.
> doesn't Ubuntu use an interface similar to this one?

Plugins and kernel modules... are more difficult.. and go right back
to the subtle but more difficult question of how users are expected to
discover or find applications at all.   For items that don't fit
intuitively as menu items, you can extend the menu metaphor to include
a "Search for Software" dialog. So for example, users who are looking
for mp3 support  would fire up the "Search For Software" dialog from
the menu layout and search for mp3.  The resulting list of packages
and short descriptions should be enough for users to use to install
the plugin package they want.

Take a good look at the UI for the gnome "Search for Files" dialog
from the gnome menu. I think a lot of the UI from that dialog could be
mapped over to software installation functionality. Repos instead of
folders,  and things like Tag "whatever" contains the text "this text"
 with a pull down menu for package tags, so you can do very refined
searches by adding multiple tag related alpha-numeric searches.    
This should be as intuitive to any user who is use to using the gnome
menu as a primary way of interacting with their system.
Can it be more intuitive than that?

-jef




More information about the fedora-devel-list mailing list