Re: Every second year we are talking about a proper installer
Hi Ole,
On Sun, Apr 03, 2016 at 12:29:58PM +0200, Ole Streicher wrote:
> I have been looking into this a bit and think I have a (compromise)
> solution.
>
> The main problem with tasksel is that it is based on debconf that has a
> very limited user interface. Basically, it can just show a list where
> one can select one or more items. This makes it impossible to have a
> detailed selection of all available blends with all their tasks -- the
> list would just get far too long: we have currently ~270 tasks in our
> blends!
>
> So, I would propose the following: At installation time, we include for
> every blend (that wants to be there) one selectable item. Selecting this
> item will install
>
> * the "tasks" package of this blend
> * all available tasks (or a subset of them? to be discussed)
>
> When starting tasksel at run time, the list will then include a list of
> available tasks for the selected blend(s).
>
> To do this technically, we could create a new package with "Priority:
> important" that just contains the tasks list. This package would then
> get installed with the base system and available for tasksel at
> installation time (right?). This way, the blends team would keep control
> over the included blends and would not need to file a bug against
> tasksel every time we want to adjust this.
>
> Does anyone veto the creation of such a package?
No veto. I agree its a compromise working around a missing feature in
tasksel. I'm a bit astonished that tasksel does not support any submenu
(I somehow might dreamt about it - I never checked).
> We would also need to create an additional metapackage for each blend,
> containing all its tasks (or a blends defined subset). Such a task would
> anyway be nice to enable a "one-stop install" with apt, f.e. with "apt
> install astro-all".
This could be generated automatically by the Blends framework either by
automatically add everything where "Metapackage: no" is not set or by
an additional flag inside the tasks to have more detailed control.
> This proposed way to present the blends in the Debian installer is very
> limited for sure - volunteers are definitely welcome here. I'd take it
> as "better-than-nothing" however.
+1
> Following the bug, we should decide which blends should be presented
> there. For a few, it seems obivous to me:
>
> * Debian Astro
As far as I have seen your latest commits (at least your private mail to
me) Debian Astro was missing. Please double check.
> * Debian Med
> * Debian GIS
> * Hamradio
> * Debian EzGo
> * DebiChem (?)
> * Debian Games (?)
>From my perspective the (?) can be dropepd since both are fine.
> I'd rather not include Debian Science -- I would see no user base for it
> as a whole (and we can only use a single default install).
I agree that installing all tasks might not make any sense. However, we
might agree upon a small set of tasks like tools, typesetting and
viewing. A proper description of the science-all task might give a hint
to the users about all those other tasks. This on one hand uses the
chance to advertise Debian Science and on the other hand is installing
packages all scientists might want on their machine.
> What about
> Debian Junior?
I would add this (even id Debian Junior is quite silent :-().
> Debian Multimedia?
No idea. Lets decide Debian Multimedia maintainers.
> And there are a few blends, that don't have tasks lists: Debian Design,
> FreedomBox, DebianParl.
Jonas?
> And, finally, there is NeuroDebian which I guess could be included, but
> this would require some input from them.
I'm keen on hearing this. :-P
Thanks a lot for your effort
Andreas.
--
http://fam-tille.de
Reply to: