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

Bug#543256: tasksel maintainer's perspective

(debian-cd added in CC with full quote of original mail)

On Tuesday 25 August 2009, Joey Hess wrote:
> A problem with providing some global way of turning off recommends by
> default in d-i is that tasks are now being maintained with the implicit
> and explicit assumption that recommends are installed by default. So,
> if recommends are turned off, tasks can be broken in both subtle and
> obvious ways.

Without apparently any consideration for how this breaks CD images.
As you well know, debian-cd currently does NOT have any functionality 
allowing it to include Recommends on a particular image, like the first 
CD. Even if it did have such functionality, it would in my expectation be 
completely unworkable as activating it would mean way too many packages 
would suddenly want to be included on CD1.

Of course we already had that problem to some extend as non-key packages 
were not necessarily available, but this will greatly increase the issue 
as packages that were previously included because they were Depends, will 
now get moved back all the way down to the "inclusion based on popcon" 

I also worry what the change will mean for the total size of the various 
desktop installs. Is the 3GB check still enough? Somehow I doubt it.

> Frans touched on this in his mail, but AFAIK the set of "required
> recommends" is much larger than busybox and libgl1-mesa-dri[1]. See
> tasksel's changelog for 2.79 for many more, and note that more will
> have a tendancy to be added over time. Also note that the (er, my)
> inability to keep track of such required recommends is why recommends
> were turned on in tasksel in the first place.

To be honest I don't feel most of those listed in 2.79 are anywhere close 
to the same priority as the two I mentioned.

> Also, the gnome metapackage is being maintained with similar implicit
> and explicit assumptions about recommends. And reversing that may not
> be to the taste of the maintainers or users of the package. For
> example, I'm about to file a bug requesting that network-manager-gnome
> be demoted to a recommends.

Losing network-manager-gnome from CD1 seems like a fairly major issue to 

> Knowing that recommends will be installed 
> by default gives the maintainer the ability to support such tweaks
> while still being sure that users who install the package will get a
> usable and standard gnome system. If the maintainer has to worry about
> users who choose to disable all recommends, he will be forced to keep
> network-manager a depends. Thus, supporting users who want to disable
> all recommends tends to reduce the total configurability of Debian.

IMO maintainers of desktop tasks do *not* have to worry about this. Such 
consequences are clearly for the user who chooses to install without 
Recommends enabled. If you chose that option, you definitely do not have 
the right to expect a "fully usable and standard system". But that does 
not mean the option is completely without merit.

I also don't think this option will be used by people doing desktop 
installs using tasksel. They are much more likely to install a normal 
base system and selectively build their desktop on top of that.
If they use a proper package manager for that, they will have plenty of 
opportunity to review which recommends they do and don't want.

> IMHO the best we can do is to implement the option, but document it as
> likely to install a broken system unless the user manually knows just
> what missing bits to install.

Which is *exactly* what I indicated in the draft template I proposed in my 

I think that, based on the reactions in the tread, we should drop the 
template in my patch for base-installer. Instead I think we should have 
the option only preseedable and as a boot option. For the latter I 
suggest defining an alias instead, so you'll be able to boot with

> Or not implement the option, which seems equivilant from here.

Not from here.

> (BTW, did you notice the annoying samba questions when installing the
> desktop task? It was an unncessary recommends in cups, which was quite
> quickly fixed once brought to the package maintainer's attention.)

I've seen other such BRs closed by various maintainers. In most cases with 
proper argumentation, even if I did not agree with it in all cases.


Reply to: