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"
level.
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
me.
> 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
patch.
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
'recommends=false'.
> 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.
Cheers,
FJP
Reply to: