Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Christian Perrier
(thanks for prodding me...you never know, indeed, though I still read 
-boot...;-) )



I have no idea whether the following is practical, and/or makes sense
regarding d-i's logic, etc., but I'm wondering whether it would be
possible to have checking "Debian Pure Blends" activate a follow-up
screen which would list all Blends. This way, we would get the previous
tasksel screen back, and only present the Blends to users who're
actually asking for it. And that, without changing anything in debconf,
its (non-)support for structure prompts, etc. Merging two tasks lists
obtained in two stages shouldn't be too hard, I suppose. But does that
make sense?

Again, Christian is more knowledgeable in this area, and might have more
insight.


I tried to read the whole thread and then I'll summarize my thoughts.

At first, I'm not happy with the idea of Pure Blends tasks mixing up 
with standard tasks. I fully respect the work done by the variou sblends 
teams, but having our usual longstanding "standard" tasks kinda lost in 
the middle of "strange" and obscure tasks which the average user has no 
idea about what they're about...is a no-no for me.


I still remember Joey's objections about *not* having users forced to 
choose between desktop environmentsbecause, contrary to what the 
average geek thinks, most people have no idea about what is a desktop 
environment. So, just imagine if we present them with "Hamradio", 
"NeuroDebian", "Debian Med" and such a list of unsorted strange things.


Not to mention that most of these tasks titles wouldn't be translated, 
while other tasks are.


So, yes, I'd object strongly to mixing up Blends tasks with other tasks.

I think that the idea of blends choice in the boot menu has already 
ruled out for several reasons, so I won't develop here, but just add one 
more reason : this is untranslatable.


That leaves us with the idea of a "Debian Blends" choice in the standard 
task menu, which would lead to a dedicated "blends" menu. I think this 
is the best compromise to do, provided we find a good name for the menu 
entry : "Debian Blends" or "Debian pure Blends" is a great name for the 
project in its entirety...but probably not for the menu entry. Again, 
because it means nothing to Joe User.


So, with something like "Special-purpose packages" or "Specialized 
installations" or whatever along those lines, *then* a menu with the 
Blends list (unsorted) and the possibility of going back just in case 
people see the list and think "heck, I have no idea about what this 
stuff is about"then I'd say this is the way to go.







Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Andreas Tille
Hi,

[due to traveling to some Debian Med related workshop in Paris I was a bit
 offline-ish - so I become involved a bit late into this discussion and
 just add my points where I think further input might be helpful.]

On Tue, May 17, 2016 at 02:00:14PM +0200, Ole Streicher wrote:
> 
> > I have no idea whether the following is practical, and/or makes sense
> > regarding d-i's logic, etc., but I'm wondering whether it would be
> > possible to have checking "Debian Pure Blends" activate a follow-up
> > screen which would list all Blends.
> 
> In the current solution, people without the need to select a blend have
> everything on the first screen, and only those who want to see all
> blends are required to scroll down *once*. So, it requires the same (or
> even less) interaction than your proposal.

Structure wise I agree with Cyril that some follow-up screen would make
some sense provided that we have some explanation what "Debian Pure
Blends" are.
 
> It also needs no change in the installer at all. What I would much more
> like to see would be some help texts -- currently one has to guess what
> "Debian EzGo" means (or "standard system utilities"). It would be nice
> if tasksel would actually display the detailed description that is in
> the tasks pages.

Fully agreed here that some extra information would be really helpful
(fully orthogonal to the Blends topic).  I personally decided to go with
the minimum selected tasks since I was lacking information what the
tasks might be install on my box.
 
As a conclusion I agree with Ole that his current proposed solution is
acceptable for practical cases since it does not require any additional
user interaction and we do not have the technique that might be needed
to realise other more structured solutions.

Kind regards

Andreas.

-- 
http://fam-tille.de



Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Steve McIntyre
On Tue, May 17, 2016 at 02:23:48PM +0200, Cyril Brulebois wrote:
>Wolfgang Schweer  (2016-05-17):
>> The 13 blends would only show up if 'blends options' is chosen in the 
>> main menu. The main menu would only have one additional entry.
>
>It's OK for boot options to control the type of installation/rescue you
>want to be using; not really to decide which questions to ask at the
>tasksel step. (Desktop choice was there for historical reasons until it
>moved to tasksel.)

Exactly - it's much better to have it later. Imagine if the top-level
boot menu permutations along with speech installation, advanced, etc...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.



Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Ole Streicher
On 17.05.2016 13:29, Cyril Brulebois wrote:
> Ole Streicher  (2016-05-17):
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> Well, I suppose this is quite a reasonable thing for someone interested
> in having Debian Pure Blends in this menu to see it as non-problematic?

Could you explain why you think it is problematic? The list is still
short (less then two screens), the Blends are well-separated (as much as
possible with debconf), for the non-iterested everything is on the first
screen, and the scrollbar clearly indicates that there is more.

> First things first: I don't think what NeuroDebian wants is going to
> happen within d-i, no. Not the place, and we have package managers for
> that.

In the moment, they place icons on the desktop to allow users to install
the major packages they want. *This* is ugly, imo. And it shows that the
current installer lacks this support, even if you (and I, BTW) don't
need it here.

> I have no idea whether the following is practical, and/or makes sense
> regarding d-i's logic, etc., but I'm wondering whether it would be
> possible to have checking "Debian Pure Blends" activate a follow-up
> screen which would list all Blends.

In the current solution, people without the need to select a blend have
everything on the first screen, and only those who want to see all
blends are required to scroll down *once*. So, it requires the same (or
even less) interaction than your proposal.

It also needs no change in the installer at all. What I would much more
like to see would be some help texts -- currently one has to guess what
"Debian EzGo" means (or "standard system utilities"). It would be nice
if tasksel would actually display the detailed description that is in
the tasks pages.

Best regards

Ole



Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Cyril Brulebois
(Christian: sorry for pinging you directly, but I need some longtimer
wisdom for this touchy topic.)

Hi,

Ole Streicher  (2016-05-17):
> I don't see it problematic as it is in the moment: The list is not too
> long: Even if it does not fit on one screen, the rest is visible with
> just one scroll, and this is indicated by the scroollbar. And I don't
> think that the number of options is too much (it shouldn't be much more,
> however).

Well, I suppose this is quite a reasonable thing for someone interested
in having Debian Pure Blends in this menu to see it as non-problematic?

I'd be interested in hearing what Christian thinks about it. What is
presented to users has always been carefully weighed to make sure d-i
is flexible yet not intimidating or confusion-generating. It looks to
me we might be making a step in the wrong direction.

While this is OK(-ish) for an alpha release, this seems like something
that should be addressed before stretch is out.


> > Also, not sure about the (lack of) ordering in Debian Pure Blends.
> > The Debian desktop environment submenu might be considered a bit special
> > (esp. after the default desktop changes…), but I don't see why the DPB
> > one should be unsorted. (See attached tasksel-unsorted-greyscale.png)
> 
> There is no specific order of the blends. One might think of some
> structuring -- many blends are somehow science related, while others are
> not --, but there is not much more to say about the internal structure.
> And I have no idea how to get a better order even in this sense. In the
> moment, they are alphabetically sorted, and this somehow reflects the
> order they appear in the blends web page [1]. It also may help to find a
> specific blend. Another idea would be to sort by popconn, but this is
> not transparent to the end user. And, other than that, I see nothing
> that would make list f.e. Debian Astro before or after DebiChem.

Ah, they are kind-of alphabetically sorted, but "Hamradio" has no
"Debian", then we have some variations depending on space between Debian
and *, but not for DebianMultimedia, etc. My bad.

> To improve that, two things have to be done: First, the tasksel
> mechanism should allow ordered lists (in the moment, they are
> automatically sorted as long as they have the same priority) -- please
> open a bug report for this, if needed. Second, we need a good idea *how*
> they should be actually ordered so that a specific blend can easily be
> found. Do you have a proposal?

This was just a minor point really, we can forget about this (see
previous paragraph).

> One problem here is the limited support of debconf for structures: there
> is one (hackish) level of sections (eaten up by the "Debian Pure Blends"
> section), but no folding or similar. Since this is discussed now over
> years without anyone actually implementing an improvement here, I doubt
> that that willbe changed before the next release, so we need something
> that works in the current scheme (well, unless *you* volunteer to
> implement this ;-) ).

(If you think I'm not busy enough…)

> And I also think that for an installer, there
> should not be too much structure, since this makes the installation too
> complicated. On the other hand, the current implementation is criticized
> by some blends, f.e. NeuroDebian, who wishes a specific selection up to
> the package level here.
> 
> Do you have any proposals what should be changed?

First things first: I don't think what NeuroDebian wants is going to
happen within d-i, no. Not the place, and we have package managers for
that.

I have no idea whether the following is practical, and/or makes sense
regarding d-i's logic, etc., but I'm wondering whether it would be
possible to have checking "Debian Pure Blends" activate a follow-up
screen which would list all Blends. This way, we would get the previous
tasksel screen back, and only present the Blends to users who're
actually asking for it. And that, without changing anything in debconf,
its (non-)support for structure prompts, etc. Merging two tasks lists
obtained in two stages shouldn't be too hard, I suppose. But does that
make sense?

Again, Christian is more knowledgeable in this area, and might have more
insight.


KiBi.


signature.asc
Description: Digital signature


Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Ole Streicher
Hi Wolfgang,

On 17.05.2016 11:52, Wolfgang Schweer wrote:
> On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
>> On 17.05.2016 02:13, Cyril Brulebois wrote:
>>> I'm not sure how reasonable it is to have such a long list of meta
>>> packages in the installer. See attached tasksel-gtk-greyscale.png for
>>> the initial display with the graphical installer, and attached
>>> tasksel-text-greyscale.png for the text mode installer.
>>
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> I'm just wondering if the blend install could be implemented one level 
> higher using the ISO image isolinux menu structure.

The advantage of the boot menu would be that in the tasksel step, one
could select individual tasks for the selected blend, and not just a
default installation. This would, however, still not allow a selection
on the package level as it was requested for NeuroDebian.

This would however add all the 13 blends to the boot menu, making this
much more crowded. And it would be impossible to select two blends at
the same time (say: science and astro).

It would also feel the Blends as being more separated from Debian
itself: you could either install "Debian", or one of the Blends. The
tasksel approach would make clear what they are in reality: a
comprehensive selection of packages and (maybe) configuration for a
specific need.

I would opt for the current solution of having it in tasksel and not in
the boot menu; especially since it is now already implemented (after two
years of discussion), with all the infrastructure and needed changes in
blends-dev in place. IMO the better solution is now to push tasksel for
a better structured package selection.

> All blends would need their own debian--install-udeb and 
> debian--profile-udeb; these need to be on all official 
> Debian installation media if these should work like the mini.iso image. 

Extrapolating the slow development on the common blends-install subject
in the last years (especially in bug #758116), I would not expect this
to happen before the next release. The tasksel approach also has the
advantage that it is semi-centralized: all Blends get a default install
of all their tasks, and they may adjust this in their debian-
package if needed.

Best regards

Ole



Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Wolfgang Schweer
On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
> On 17.05.2016 02:13, Cyril Brulebois wrote:
> > I'm not sure how reasonable it is to have such a long list of meta
> > packages in the installer. See attached tasksel-gtk-greyscale.png for
> > the initial display with the graphical installer, and attached
> > tasksel-text-greyscale.png for the text mode installer.
> 
> I don't see it problematic as it is in the moment: The list is not too
> long: Even if it does not fit on one screen, the rest is visible with
> just one scroll, and this is indicated by the scroollbar. And I don't
> think that the number of options is too much (it shouldn't be much more,
> however).

I'm just wondering if the blend install could be implemented one level 
higher using the ISO image isolinux menu structure.

As an example:

It is pretty much possible to install the Debian Edu blend using the 
stock Debian mini.iso image (works, cause all udebs are fetched from the 
net in this case):

wget https://d-i.debian.org/daily-images/amd64/daily/netboot/mini.iso

On the kernel command line add: 
anna/choose_modules=debian-edu-install-udeb (the additionally needed 
debian-edu-profile-udeb will be pulled in as a dependency).

To get it working w/o touching the kernel command line, modify the ISO 
image (btxt.cfg is the blends text install config file):

modified menu.cfg
-
menu hshift 7
menu width 61

menu title _Debian GNU/Linux installer boot menu
include stdmenu.cfg
include gtk.cfg
include txt.cfg
menu begin advanced
menu label ^Advanced options
menu title Advanced options
include stdmenu.cfg
label mainmenu
menu label ^Back..
menu exit
include adgtk.cfg
include adtxt.cfg
menu end
menu begin blends
menu label ^Blend options
menu title Blend options
include stdmenu.cfg
label mainmenu
menu label ^Back..
menu exit
include btxt.cfg
menu end
include x86menu.cfg
label help
menu label ^Help
text help
   Display help screens; type 'menu' at boot prompt to return to this menu
endtext
config prompt.cfg
include spkgtk.cfg
include spk.cfg


added btxt.cfg (with debian-astro just as an example showing up in the menu)

label edu blend
menu label Edu Blend install
kernel linux
append vga=788 initrd=initrd.gz 
anna/choose_modules=debian-edu-install-udeb --- 
label astro blend
menu label Astro Blend install
kernel linux
append vga=788 initrd=initrd.gz 
anna/choose_modules=debian-astro-install-udeb --- 


All blends would need their own debian--install-udeb and 
debian--profile-udeb; these need to be on all official 
Debian installation media if these should work like the mini.iso image. 
The Debian Edu udebs could be used as examples to create blend specific 
ones:

git clone git+ssh://git.debian.org/git/debian-edu/debian-edu-install

Wolfgang


signature.asc
Description: Digital signature


Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

2016-05-17 Thread Ole Streicher
Hi Cyril,

thanks for your response.

On 17.05.2016 02:13, Cyril Brulebois wrote:
> I'm not sure how reasonable it is to have such a long list of meta
> packages in the installer. See attached tasksel-gtk-greyscale.png for
> the initial display with the graphical installer, and attached
> tasksel-text-greyscale.png for the text mode installer.

I don't see it problematic as it is in the moment: The list is not too
long: Even if it does not fit on one screen, the rest is visible with
just one scroll, and this is indicated by the scroollbar. And I don't
think that the number of options is too much (it shouldn't be much more,
however).

> Also, not sure about the (lack of) ordering in Debian Pure Blends.
> The Debian desktop environment submenu might be considered a bit special
> (esp. after the default desktop changes…), but I don't see why the DPB
> one should be unsorted. (See attached tasksel-unsorted-greyscale.png)

There is no specific order of the blends. One might think of some
structuring -- many blends are somehow science related, while others are
not --, but there is not much more to say about the internal structure.
And I have no idea how to get a better order even in this sense. In the
moment, they are alphabetically sorted, and this somehow reflects the
order they appear in the blends web page [1]. It also may help to find a
specific blend. Another idea would be to sort by popconn, but this is
not transparent to the end user. And, other than that, I see nothing
that would make list f.e. Debian Astro before or after DebiChem.

To improve that, two things have to be done: First, the tasksel
mechanism should allow ordered lists (in the moment, they are
automatically sorted as long as they have the same priority) -- please
open a bug report for this, if needed. Second, we need a good idea *how*
they should be actually ordered so that a specific blend can easily be
found. Do you have a proposal?

One problem here is the limited support of debconf for structures: there
is one (hackish) level of sections (eaten up by the "Debian Pure Blends"
section), but no folding or similar. Since this is discussed now over
years without anyone actually implementing an improvement here, I doubt
that that willbe changed before the next release, so we need something
that works in the current scheme (well, unless *you* volunteer to
implement this ;-) ). And I also think that for an installer, there
should not be too much structure, since this makes the installation too
complicated. On the other hand, the current implementation is criticized
by some blends, f.e. NeuroDebian, who wishes a specific selection up to
the package level here.

Do you have any proposals what should be changed?

Best regards

Ole


[1] https://www.debian.org/blends/