man, 23.05.2005 kl. 17.55 skrev Jeff Spaleta:
> On 5/22/05, Kyrre Ness Sjobak <kyrre@xxxxxxxxxxxxxxxxxx> 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.
>
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.
About web portals - some migth want to use this functionality, such as
happypenguin. They could now offer a link ("install this app"), which
points to a .install file, which is handeled by this installer app. Same
app would also install "naked" rpm's from nautilus, using yum to resolve
deps.
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"? 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).
> 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.
>
Agreed.
> > 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.
>
Interesting, but that removes the "browse" aspect.
There should be a description of what each package do as well. And the
"yum groupinstall" thing should be closely mapped in the ui.
> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
