Re: Every second year we are talking about a proper installer
thank you very much for your feedback!
Andreas Tille <email@example.com> writes:
> On Sun, Apr 03, 2016 at 12:29:58PM +0200, Ole Streicher wrote:
>> 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).
tasksel currently supports one level of submenu, and this could be
extended. BUT: this submenu stuff in tasksel is a dirty hack. It just
resorts the entries so that everything belonging to a submenu is grouped
together, and adds a "..." in front of each entry. No fold-in or such.
For us (>>250 tasks) this is unsuitable.
>> 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.
I added a default $blend-all task to the blends package that just
recommends all other tasks of the package. This is probably a good
If needed, I would propose a new flag "Install:" which defaults to "yes"
(so, by default all packages are included). Set it to "no" if the
task shall not installed by default.
>> 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.
This was since I generated the screenshot with Debian Jessie, and there
is not astro-tasks package on Jessie.
>> * 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.
The problem here is that tasksel does not provide any further help than
what is on the screen. So, if you have a description, please feed it
into the blends package.
>> 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.
>> 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
I am really surprised that we have a blend that is in a really nice
shape and does/did a lot of promotion, but is nearly invisible within
Debian. I even have no ideas whether NeuroDebian has "tasks".
What is the way to contact them?
> Thanks a lot for your effort
I pushed some changes to the blends package: mainly the creation of the
package with the tasks list for the installer tasksel, and the automated
creation of the $blend-all metapackages.
I am not an uploader of the package, and I would ask to review this
stuff. If it appears fine, we should upload ASAP. I'd expect some
discussion about the inclusion of a new "Priority: important" package,
and we need the changed blends-dev package to actually create the
$blend-all tasks for all affected blends, which again need to go via
NEW. So, let's do it while NEW is quite short and all are relaxed. And
we need some testing, preferred with the next installer prerelease.