[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Recommends for metapackages

Thibaut Paumard <paumard@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

>>> 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

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.


Reply to: