Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
(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
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
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
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
(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
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
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
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/