On Thu, 2006-11-30 at 20:51 +0100, Nicolas Mailhot wrote: > Le jeudi 30 novembre 2006 à 13:45 -0500, Jesse Keating a écrit : > > On Thursday 30 November 2006 12:29, Toshio Kuratomi wrote: > > > 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. > > > > Why do all packages have to be listed in comps? The grouping metadata can > > list packages being in some groups, and then if a package isn't in any group, > > the tool (apt/smart) could represent that as 'Ungrouped' or however you want > > to phrase it. > > Why to you want to impose the policy of one user of this file (anaconda) > on others ? Because the file exists to provide the metainformation needed for a specific UI -- that used by anaconda and pirut. > Defining groups for anaconda use and lumping everything else in an > anaconda-does-not-care limbo is not the answer. It's not anaconda doesn't care, it's that *USERS* don't care. There definitely are groups that _are_ end-user interesting that aren't present. And when those come up, it's easy. But this crusade to list every package in comps is explicitly _not_ what comps was ever intended to be. > The answer is to categorise everything, and let apps define the > filtering they want separately. And what provides the information as to whether something should be filtered? Hard-coded in anaconda? That goes great with doing derivatives... Jeremy -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
