On Thu, 2006-11-30 at 10:52 -0500, Jeremy Katz wrote:
> On Wed, 2006-11-29 at 20:20 -0800, Toshio Kuratomi wrote:
> > On Wed, 2006-11-29 at 22:49 -0500, seth vidal wrote:
> > > I don't see anything stopping that from happening now.
> > >
> > > Either:
> > > 1. write the above interface for repodata and then have yum be able to
> > > understand that info
> > > 2. use the existing comps format and just have yum be able to look up
> > > pkgs by the group they belong to. So for the above you would do:
> > > Take the intersection of /Language/Python, /Development/Library,
> > > and /Security/Cryptography and display those pkgs.
> > > Then comps looks like:
> > >
> > > <group>
> > > <name>/Security/Cryptography</name>
> > > <package>python-gpgme</package>
> > > <package>gpgme</package>
> > > <package>gnupg</package>
> > > </group>
> > > <group>
> > > <name>/Development/Library</name>
> > > <package>python-gpgme</package>
> > > <package>gpgme</package>
> > > </group>
> > >
> > So perhaps all we need is free reign to do this in comps. Which, from
> > previous messages from jeremy, seems to imply we would need to have
> > separate comps.xml files for the installer and for the repo.
>
> The "problem" is that if you do something like this, you _really_ don't
> want to be using the current UI.
There's an assumption here of what the current UI is. From your
background and the background of comps I would assume that "current UI"
means anaconda's interface. However, comps.xml has been proposed as a
replacement for the rpm group tag in general. Repoview already attempts
to do this (with a horrible number of entries in the uncategorized
listing). apt/synaptic and smart currently use the rpm group tag and it
was proposed that they should be ported to use comps instead of
rpm::group. I would say that apt and smart's UI would not suffer from a
migration to comps provided that comps lists all the packages in the
repository.
> Rather than focusing on the question
> of "how do I fit this in comps" or "how do I list every package because
> oh my god, how else do I find something", the _real_ question is trying
> to figure out what the user experience we're trying to get at is, get
> some mock ups and then figure out what the "right" implementation path
> is from there.
>
User Experience
Objective
Allow a user to view a subset of packages in a set of repositories
that matches categories of software that they are interested in
installing. This allows the user to more quickly discover a package
that fills a need for them.
Interface1
1) Select a group from all groups valid for the repository
2) List all packages which match that group.
3) Allow the user to select another group from the groups that these
packages have.
Repeat from 2 until A) the list of other groups would have a single
entry, B) there's only a single package in the package list. C) User has
left this interface
Interface2
yum groupsearch Development Python Cryptography
Finds all packages in the repositories whose group information
contains all of those patterns.
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
