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 d-i) 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! Thanks. -- cheers, Holger
Attachment:
signature.asc
Description: Digital signature