New Comps Groups

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061130/89874513/attachment.sig>