New Comps Groups

[Toshio Kuratomi]

On Fri, 2006-12-01 at 10:36 -0500, Jeremy Katz wrote:
> On Thu, 2006-11-30 at 22:45 -0800, Toshio Kuratomi wrote:

> > You are talking about what you wanted from the installer.  But that's
> > not necessarily relevant to what you want from a graphical package
> > manager.  Or from a web based package lister (a la repoview).  repoview
> > doesn't need to worry about multiple selection of packages, for
> > instance.
> 
> This confirms my suspicion that we're talking past each other :-)
> 
I had that impression as well :-)

> But yes, different interfaces want different metadata.  The crux of my
> argument is that "comps.xml" isn't the metadata for that purpose.  And
> with repomd, we now have the ability to drop in arbitrary metadata and
> they only get fetched by the tools trying to use them.  Trying to make
> it so that we handle every possible use case with one file just isn't
> going to work, IMHO. 
> 
Possibly.  Having separate files is good because each one can be
designed specifically for the purpose they are designed for.  Having
separate files is bad because you have to add similar information in
several places and you have to write more code for tools that want to
parse both pieces of information.

> So yes, for a web based package tool (son of repoview), there are
> different sorts of things you're going to want.  To be Web 2.0-y, you
> probably want arbitrary tagging of packages, linking between tags, etc.
> And that's _awesome_ for a web presentation.  It sucks rocks for a
> native UI.
> 
Nah.  It sucks rocks for the installer.  It can make sense in a native
UI as well.  It depends on how you're using the native UI.

> > > >   Interface2
> > > >     yum groupsearch Development Python Cryptography
> > > >     Finds all packages in the repositories whose group information
> > > > contains all of those patterns.
> > > 
> > > Search is *definitely* something that's incredibly useful and important.
> > > Realistically, it's probably more interesting than browse for most use
> > > cases.  Can the search that's currently there be improved, yep.  Was
> > > easiest to just start with 'yum search' and then improve from there.  
> > 
> > search and browse are very different.  I would say that browse is at
> > least as useful to get right as search, possibly more.  Search works on
> > the principle that you know what you are looking for, you just don't
> > know its name.  Browse works on the principle that you sense what you
> > are looking for, you just don't know how to express what that is.
> 
> When looking for software, which do you do first?
>   a) Go to google, put in some keywords, search
>   b) Go to freshmeat/sourceforge and browse through their "troves"
> 
Just because the browsing tools are inferior to the search tools doesn't
mean that browsing is inferior to search.  Most of the time, my research
on the internet involves both search and browse.

A) Use google to search for some keywords.
B) Then browse the links of related pages, opening five to ten of the
most likely hits.
C) Read one of the pages and browse to other pages linked off of that
one.

Do you use google exclusively to find information on the Internet or do
you browse the hyperlinks from the pages you visit?

> Or for a non-software analogy, how do you find stuff at Amazon?  Do you
> search or do you go through the stores and walk through the long lists
> of stuff?  While I used to "browse", the amount of stuff is just too
> overwhelming now and I almost always search for something and then use
> the "related items" to go explore more.
> 
Even you are using browse :-)  Related items is a browsing interface.

In a brick and mortar bookstore or library, the equivalent is searching
for a section of books you're interested in (a particular author, a
particular genre, a particular subject) and then browsing the books
there to decide which one you're going to get.

I notice two things in all three of these examples:
1) The entry point to all three is a search interface.
2) The browse function is independent of the keywords entered into the
search.  Instead it depends on other people having manually organized
the data to begin with.

Side Notes about Google "search":

Google is interesting in that it has a pure search interface in its "I'm
feeling Lucky" action.  I never use it.  I always search and then browse
the returned information to perform my own sorting and qualifying.

Even if you don't click on any of the links returned by search until
you've refined the keywords you enter into the search box to return what
you were interested in on the first page, chances are you've browsed the
summaries of other pages to find ideas and keywords to refine your
search.

-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/20061201/5ca26489/attachment.sig>