Bug#825004: blends-dev: undesired new Task $blend-all package
On 24.05.2016 10:06, Holger Levsen wrote:
>> I am not sure whether I understand you specific problem correctly: Do
>> you want to have a way to select individual tasks, or a way to disable
>> it for the whole blend?
> We dont want a broken and uninstallable education-all package.
> Right now this breaks building the debian-edu package from source in sid
> for us. (Well, or rather it breaks the prequisite, the make dist step.)
The current solution is to opt-out the tasks that shall not be there. As
I said, this may be easily changed to opt-in, and then create the -all
package if there was *any* opt-in package.
> the implementation of #758116 is still in flux, so I would like to
> suggest a third option: allow to install something else than
> "blends-all" from tasksel.
I would guess that for any (compromise) solution will have a
debian-blends-tasks.desc file which defines which tasks come from the
This file is located in the "blends" package; you can easily edit the
debian-edu section and put there what you want. Combined with the
removal of the -all package (which seems the way to resolve this bug),
you get all flexibility.
> Because we already have these metapackages which are suited for that, we
> just dont have an education-all metapackage because that's simple not
> useful for us.
> What comes _close_, is education-standalone, possibly combied with
> But then it would also be great, if it were possible to install
> education-mainserver or education-thin-client-server.
The problem IMO here is that we need a compromise: tasksel is not
flexible enough to show a detailed choice of options for every blend;
bug #758116 shows that there is resistance even to have *one* option per
blend. I still think this is the best compromise we can get (maybe on an
extra page that is enabled somehow). If you disagree you should make
this clear in the mentioned bug -- and/or we should discuss other
options in the debian-blends mailing list.
> And some more. Actually, best have a look at
> to see the options we currently have.
Yes, this is nice. It would be perfect if we had this for all blends,
from the default Debian image, without voodoo (like some magic keystroke
on the bootprompt).
> option 2 is something which makes sense to us. (I repeat: the current
> implementation broke our workflow to do releases in sid.)
OK, I will implement it as following:
* Tasks that are going into a "<blend>-all" metapackage are marked with
"Install: true" (so, opt-in instead of opt-out)
* If no task has "Install: true", no <blend>-all metapackage will be
Please give me some time, since before that I would like to add the
"Install: true" to debian-science and debian-astro.
> but then, we also want to be presented as part of the blends presented
> via regular d-i (#758116), so I think it would be best to allow other
> packages than %blends-all to be presented there.
Sure; just change the debian-blends-tasks.desc file in the "blends"
source package accordingly.