Russ Allbery <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> But that doesn't realy solve the problem on its own. It would be nice if >> packages could be consistently taged with "Application: >> yes|no|<untaged>" signifying that this package is usefull on its own >> (foo), will never be used alone (foo-data, libfoo) or is >> ambigious. Frontends should then hide anything with "Application: no" >> under normal operations. > > This is a really interesting idea, particularly if it were combined with > an implementation recommendation to stop suppressing Application: no > packages if they're listed in Suggests of an installed package or list an > installed package in Enhances. That way, documentation packages could be > listed in Suggests but otherwise be Application: no, since the sort of > user who doesn't want to see all the library packages is probably also not > going to want to browse the list of documentation packages for packages > they don't have installed.
Or a "Package-Type: application | lib | data | doc | dev | common | dummy". A yes/no field is hard to extend to more cases. As a bonus the 'Package-Type: dummy" would be packages needed to handle package renames or replacements and can be savely purged on the next aptitude/debfoster/deborphan run. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]