Thibaut Paumard <paum...@users.sourceforge.net> writes: >> That also achives maximum annoyance, because if I want the full >> platform, I'll have to go recommends/suggest hunting. (No, I'm >> *not* going to turn on install-recommends.) > > You don't want to turn on install-recommends, but you are happy with > installing a loaded meta-package such as "gnome" or "kde-full"?
I am happy with installing gnome, because I (or my parents, in case of my desktop) use pretty much all of it from time to time. Would I find something in it that I never use, and would it eat enough space or other resources to annoy me, I'd do my own local meta-package instead, that wouldn't have the unnecessary parts. The reason I do not turn on install-recommends, is because in the vast majority of cases, I do not need the recommended packages. Removing them by hand is much more work than installing the few that I do need. This isn't the case for the gnome meta-package. As for kde-full: no, I'd never install it. There's one kde thing I use, kcachegrind, and I'm happy to install that by hand. Would I be a kde user, I would probably not install kde-full either, because - by the looks of it - there would be significant parts of it that I'll never use. That doesn't mean it should only recommend them, no need to, I'm perfectly capable of installing the subset I need. I am also perfectly capable of writing a script to notify me whenever the meta-package's dependencys change, so I will have the option to pull in new things if I want to. (Said script is ~10 lines, and I wrote it yesterday in about 5 minutes; less time than I spent replying to this mail.) >>> OTOH, metapackages from hell (like gnome or kde-full) based on >>> Depends require me to select them, go to the "will install these" >>> screen, deselect the meta package, and go over the list manually >>> installing whatever isn't going to be useless/unwelcome for my >>> specific case. And I will never notice if the metapackage >>> changes its dependency tree later on. >> >> You could script all that, and keep your local list up-to-date >> with about ~10 minutes of work. > > The annoyance of not being able to uninstall just one of many packages > pulled by a big meta-package does not affect only developers. A > reasonable solution should be found which works for our priority: our > users. Like I said earlier: script it. I posted a script that can remove any number of packages from another's depends line, and echo a control file. Updating that to create a local meta-package is a piece of cake. Hooking it into apt is also similarly easy, and bingo, you have a solution. Package it up, create a config file for it, and it's ready to be shipped to users. Everyone wins. The whole thing is about an hour of work with everything included for anyone who cares enough, far less than the time already spent arguing about silly things on this list. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw8ywhyf.fsf@algernon.balabit
