Re: Bug#825004: blends-dev: undesired new Task $blend-all package
Holger Levsen <holger@layer-acht.org> writes:
> 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…
Sure. I am very aware that we are far from being perfect. However, we
need to get started /somewhere/, and here we are.
>> 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?
My idea was here: We centrally define which blends go into the default
installer -- very much as it is centrally defined who is on the blends
web page. Since we currently (in my believe) will only have one option
per blend, we define just one metapackage for each blend. This
metapackage is then under control of the individual blend and may depend
on everything the blend wants to have installed in that single default
install. This one is called <blend>-all (since it was though of having
all in by default). The blends-dev framework offers a new keyword
"Install:" to select which tasks should go into the -all package.
If you feel this does not fit your needs, you now can:
* create your own edu-all package containing whatever shall go into
the default installation, or
* go one level up, edit the central blends file so that it fits to your
needs.
The latter will probably anyway needed since the description need to be
understandable by the end user, and there were already complaints that
f.e. "debian-astro" is too unclear. But I have no idea how to move this
into the individual blends packages, and the amount of changes here are
probably quite limited.
> 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!
No idea yet. You could just keep both, so there is one sophisticated
debian-edu for the people who know the magic in enabling your udebs, and
a simple one-size-fits-all solution for those who don't.
>> 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)
This is what I meant with "voodoo".
> and then we could maybe also build specific isos for these.
Sure. But to have it in the default installer serves IMO at least two
purposes: first, to make a separate ISO unnecessary for many purposes,
and second to increase the visibility (and therefore popularity) of the
blends themself.
Cheers
Ole
Reply to: