> Some argue that meta-packages can have a different purpose, and some > argue that recommending also to some (lesser) extend ensures > installation of packages. None of that, however, changes the fact that > _this_ meta-package _now_ has the feature of strictly ensuring a certain > set of packages. For those wanting that. And not for those feeling it > is in their way, but those can simply avoid that package: A meta-package > has no functionalirty beyond pulling in packages, so there is no loss to > the resulting system other than lack of its sole feature.
Error. A meta-package has functionality way beyond that. It exists not only to pull in packages, but also to allow auto removal of leaf packages when the admin decides to get rid of them, to maintain a collection of related packages together, to avoid deinstallations when upgrading libraries (aptitude has the insane actitude of proposing removal of tons of packages before proposing upgrading une of them, and if you see your loved metapackage in the list you know something is wrong with the option and press . ), pulling new software in when the collection changes, etc. So a meta-package is "just" a way of installing things together, and a lot more. But from those things, only dependencies should be Depends, and software that improves the collection should be Recommends. In this particular case, N- M improves gnome but it is not needed at all. Think on this use case: a user wants a full gnome installation and to be able to get new versions of programs (or even new substitute programs) to be automatically installed when they change on the 'gnome' package, but also wants pidgin and evolution work online while he has a static interface (not managed by n-m). This user can fill a bug against gnome-core due that it forces him to install a package that breaks the functionality of pidgin on his system. And he is right. Regards Noel Torres er Envite
signature.asc
Description: This is a digitally signed message part.
