Hi Michael, On 10.12.2016 14:48, Michael Biebl wrote: > Am 10.12.2016 um 14:15 schrieb Ole Streicher: >> Hi Michael, >> >> On 10.12.2016 13:18, Michael Biebl wrote: >>> While I have no opninion on whether blend-tasks is important enough to >>> have installed by default, I would urge to revisit the idea to (mis)use >>> the package priority to achieve that. >> >> That is the standard way how tasksel gets its menu: tasksel-data is >> marked as "important" and that way it finds its way onto the installer >> image. So, all arguments you have here are also valid for the default >> tasks. If we think this is wrong, we should get a completely different >> solution here -- which is IMO outside of the scope of this bug. > > Well, two wrongs don't make one right.
If we would remove one of them, the other would still stay there, and the problem remains. > An obvious solution seemed to me, to make tasksel(-*) depend on > blends-tasks. This why, the package would be marked as auto-installed, > and should you later decide to implement that differently, say directly > in tasksel, then tasksel can simply drop that dependency. The disadvantage is that people can't uninstall the blends task. And at least Holger clearly indicated that he wants to have this option. > I assume though you have considered this obvious solution and decided > against it for some reason? The major reason is that during the discussion of the blends into tasksel became clear that the tasksel maintainers are already overloaded. Having to manage the blends tasks here would put another work on top of that. Additionally, they have no competence in deciding neither which blends should go in, nor about how to describe them. This all done by the Blends team. So, it seems to be natural for me to have the blends tasks maintained by this team, and not by the tasksel developers. In principle, the same would be applicable for the desktop selection, however there seems to be no dedicated team for the desktop. Best regards Ole