On 06.12.2016 10:37, Holger Levsen wrote: > And this *is* still pretty confusing, though admitly better than it was > half a year ago.
The current implementation has a popcon of >5000, without a single complaint or confusion documented in the web within the last six months. This is at least *some* empirical evidence that it is not "pretty confusing", and again I would ask you to show any better empirical data here to support your own point. > and it will only get worse, if we would keep it this way… We have *many* more > blends in Debian… Debian Parl, Debian Junor, Debian Edu come to my mind > immediatly. > why list some and not some others? The "single checkbox" is not usable for all blends, since it requires a "one size fits all" solution. For Debian Edu, you already stated yourself that it is useless. Debian Junior and Debian Parl didn't opt in. I therefore don't see a danger that the list will grow endlessly before Stretch. > and that this bug should not be about this tasksel menu but *about this > was implemented*, which is by forcing an unneeded package on each and > every Debian system under the sun. (priority: important…) I already answered to this: there is no technical reason to have the blends task in an individual package; technically it could also be put into tasksel-data itself. However, this would require action from the tasksel team every time something changes in the blends task. d-i is already overloaded, and it will not help if we put another responsibility on top of that. So, it is a good solution to separate the responsibility of the "Special tasks" item to the blends team. Compared to an integrated (into tasksel-data) solution, the size impact is minimal: mainly the overhead of having an additional package there. If we care about this overhead, the problem would apply to tasksel-data as well. Best regards Ole
