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

Re: Bug#825004: blends-dev: undesired new Task $blend-all package

Hi Ole,

On Tue, May 24, 2016 at 10:33:20AM +0200, Ole Streicher wrote:
> 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.

emphasise on "current solution"… I think it has become obvious that the
current solution doesn't cover all use cases…

> I would guess that for any (compromise) solution will have a
> debian-blends-tasks.desc file which defines which tasks come from the
> blends.
> 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.

I don't think the consumers of the blend framework should be required to
modify the framework on the source level - which is how I understand
your idea of defining all the blends tasks in debian-blends-tasks.desc
in the blends package. Or did I get you wrong?

> 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.

we currently have two "incompatible" solutions for this for the Debian
Edu usecase:

a.) the current implementation for #758116 which expects a education-all
meta package to install for Debian Edu

b.) the debian-edu-profile-udeb and debian-edu-install-udeb packages
(both coming from src:debian-edu-install) which modify d-i to get the
profile question we want for Debian Edu installs.

what we are currently missing is something to make these two
"compatible", that is, after choosing "blends installation options"
during a regular debian install using d-i, one should be able to choose
"Debian Edu" and then get to our profile chooser.

Suggestions how to implement this much welcome!
> > And some more. Actually, best have a look at
> > https://wiki.debian.org/DebianEdu/Documentation/Jessie/Installation?action=AttachFile&do=get&target=08-Choose_Debian_Edu_profile.png
> > 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).

well, yes, maybe for popular blends like Debian Edu we could also add a
kernel param adding "profile=edu" or such, which takes the user directly
to that profile question (and as such implicitly enables blend mode in

and then we could maybe also build specific isos for these.

> > 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
> created.

cool. so the old behaviour (no $blends-all packages) becomes the new
default, nice!

> Please give me some time, since before that I would like to add the
> "Install: true" to debian-science and debian-astro.

sure. I'm happy to ignore this for some days and focus on jessie stuff
for the 8.5 point release instead ;-)

> > 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.

ok, I will have a look! 



Attachment: signature.asc
Description: Digital signature

Reply to: