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. 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. Jeremy -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
