What happened to pup?

[Jeff Spaleta]

On 5/24/05, Kyrre Ness Sjobak <kyrre at solution-forge.net> wrote:
> Well, no - it does not require network access. Part of it was to make
> sure you could install an rpm from a local disk, and have a repo
> configured to update this sofware.

But.. in your scheme web portals are primary way to FIND packages..
you said so yourself.

> 
> About web portals - some migth want to use this functionality, such as
> happypenguin. 

And I'm not saying do away with web portals.. im saying do not make
them the primary way by which users of the system are expected to find
software. Make the primary way a client application.. re-using as much
of the existing desktop ui conventions as is feasible.

> Hmm.. maybe what i am really thinking of could be
> "system-config-packages should use yum to resolve deps, instead of using
> rpm directly, when installing an rpm from nautilus"? 

And I'm pretty sure there is a long term master plan to make both
anaconda and whatever replaces system-config-packages yum aware.

> The ".install"
> thing could then be a wrapper (a tar.gz perhaps), containing rpms and an
> xml file with metadata - so that a third party suplyer could avoid
> special scripts etc. to setup a repo in yum + be able to pick "i want
> this, this, but not that" without needing to more or less guess what is
> within foo-bar-component-baz.rpm - and wich order they need to be
> installed in (today, there are no option of specifying "rpm -ivh foo.rpm
> bar.rpm" without using the command line).

This is overkill re-invention. repo structures exist and can be used
by any 3rd party who wants to provide a collection of packages. You
can even drop a repo structure into a tarball.
The only piece missing is a mechanism for getting a repo definition
added/removed to a configuration, everything else is something ui
experts need to mull over.

> Interesting, but that removes the "browse" aspect.
Fine... shall we add a browse softwarespace to the find dialog as
well? Look at the find dialog in the gnome menu... it has a browse
button. The menu layout still holds as a ui to shoot for.  The idea
isn't to prevent people from browsing the full space of software, the
point is to make sure there are intuitive mechanisms that make it less
likely for users to need to do a full browse. browsing the full space
is never..ever...ever going to be intuitive nor efficient.

Just like using your filebrowser to hunt for random executables on
your filesystem is something that can be done..and will be done...must
be done.. in some cases, its not what you want novice users to be
doing most of the time.   For installed applications you want users to
be able to quickly navigate a menu and then falling back to a usable
find dialog, before resorting to a brute force browse.  And I say, if
the ui works for the main menu.. it will work for an software
installation app.


> There should be a description of what each package do as well. And the
> "yum groupinstall" thing should be closely mapped in the ui.

There is no technical reason why the visible comps.xml definitions
can't be re-worked to closely align with the categorization of
applications in the main menu.  In fact i find the dissimilarity
between Core's user visible comps group definitions and the main menu
layout to be a glaring usability problem when it comes to post install
usage by novice users. A yum enabled version of system-config-packages
will still confuse novice users simply because the comps defined
groupings are not aligned well with the application categorizations
they use every day in the system menu.  How to categorize packages, is
a complicated issue. We might end up needing to provide different
comps.xml files for different purposes or intended audiences.

-jef