Bug#758116: Bug status
Hi, I am currently preparing a new Debian Pure Blend (Debian Astro), and I am curious about the status of this bug. Is this something that is going to be implemented in stretch? And what are currently the main obstacles? The last entry was from one year ago -- did anything happen behind the courtain? I would be quite interested to get this done; being visible during the installation is one of the motivations in creating a Blend. Best regards Ole
Re: Debian Installer Stretch RC 1 release
On 15.01.2017 05:21, Cyril Brulebois wrote: > The Debian Installer team[1] is pleased to announce the first release > candidate of the installer for Debian 9 "Stretch". > > > Important changes in this release of the installer > == > > * [...] > * As noted in the Stretch Alpha 6 release announcement, Debian Pure >Blends appeared in the Software selection screen. Unfortunately, >concerns voiced back then weren't worked on until after the freeze >started, and a freeze isn't the time where critical screens should >be revamped. Support was disabled accordingly. Since this is still an open discussion in #846002, I would have preferred if you would not try to force your own preference here before the CTTE made its decision. IMO your solution is not in any way cooperative and tries to make the CTTE decision useless. I therefore would ask the CTTE to make a final decision about the inclusion of the blends selection in the Stretch installer. In principle these are *two* decisions: 1. Appearance of the blends in the installer: Please decide, whether * the blends shall be shown in their current (alpha-8) form * The installer is extended to show the desktop and the blends only optionally (as propagated by Phil, and opposed by Cyril) * the blends should not appear in the Stretch installer at all. 2. Maintenance of the blends tasks appearing in the installer: * in a separate package maintained by the blends team * integrated into tasksel and maintained by d-i * be removed completely from the installation process Best regards Ole
Bug#851555: Blends install options removed from tasksel menu
Package: tasksel Version: 3.39 Severity: serious Control: block -1 by 846002 Since revision 3.39, tasksel limits the tasks to a predefined list in the installer, which ignores the blends task selection currently under CTTE discussion in #846002. The result of the discussion is still open, and this bug is created to mark tasksel as a potential target of the CTTE decision. BTW, I usually would have expected that all parties keep the status quo during the discussion until a decision is made; trying to undermine the discussion result is IMO improper and unfriendly behaviour. The change (ba4e0289) also makes it more difficult for others to add items to the installer tasksel menu for customized builds without a technical reason. And any CTTE decision will anyway make the patch obsolete. Best regards Ole
Re: Bug#846002: Debian Installer Stretch RC 1 release
Hi Bjørn, Am 17.01.2017 um 10:28 schrieb Bjørn Mork: > To me it looks like a sandbox fight which started with the creative use > of "Priority: important". Now it appears that the party starting the > fight thinks the other party should stop throwing sand until "mommy" > (aka CTTE) decides who is right and who is wrong. > > I have of course probably gotten all this wrong. But that doesn't > really matter. The above describes how *I* subjectively perceive the > situation. That is not a subject for discussion. > > My personal advice, since I'm out here providing opionions nobody asked > for anyway, would be to start co-operating with the tasksel/installer > developers instead of waiting for a CTTE decision. That's not going to > solve your issues anyway. I think that your impression is not true here: "Priority: important" is the usual way to get a package installed at install time. And we announced to do this in the relevant bug, and this reached the table of d-i, with an explicite request for a comment or veto (which did not happen). After the following discussion we limited the number of entries and changed the wording to be less confusing. There was no response or critics to this from d-i until #846002 was opened (which was too late for other changes, according to Cyril). We were always ready to co-operate here, but without a getting a response this is a bit difficult. In the meantime, tasksel was extended by another entry "LXQt", making the "we don't want add items as they increase the confusion of tasksel" argument questionable. BTW, the usual way to cooperate is to open a bug report if something seems to go the wrong way with a package. If d-i was so unhappy about blends-tasks, why didn' they open a bug in summer saying that wording change and limiting entries is not enough? Finally: Yes, it seems that we have a conflict between two teams (blends and d-i), and CTTE is asked to decide for the technically best solution. I would really ask CTTE to evaluate the "confusion" argument (which is the central one here) in order to make a decision whether the blends should go into the installation menu or not. And who should maintain it (the blends or the d-i team) -- these two were the questions raised in the beginning from Holger. Best regards Ole
Bug#758116: Every second year we are talking about a proper installer
Andreas Tille writes: > I'd like to attract your attention onto bug #758116 which is requesting > a sensible selection of Blends tasks right from the installer. 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? 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 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. Following the bug, we should decide which blends should be presented there. For a few, it seems obivous to me: * Debian Astro * Debian Med * Debian GIS * Hamradio * Debian EzGo * DebiChem (?) * Debian Games (?) 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). What about Debian Junior? Debian Multimedia? 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. Best regards Ole
Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
Control: reassign -1 src:blends Control: tag -1 pending I have created the package mentioned in my last mail in the blends git repository: https://anonscm.debian.org/cgit/blends/blends.git/ Package: blends-tasks Architecture: all Priority: important Section: misc Depends: tasksel Description: Debian Pure Blends tasks for new installations This package installs a choice of a default installation for each Debian Pure Blend when run from the Debian installer. The installation includes the tasks package of the blend, so a subsequent invocation of tasksel enables the choice of individual tasks. . The package is intended to be installed in the base system. Later (un)installation is harmless, but has no effect. I will upload the package at the weekend if there is no further discussion on this. Best regards Ole
Re: 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/
Re: 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 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
Hi Christian, I agree that the best compromise would probably be to have a separate page "Debian Pure Blends". But someone should implement this -- any volunteers? I myself don't have enough Perl knowledge to do this. However, I don't understand your rationale here: Am 18.05.2016 um 07:25 schrieb Christian Perrier: > 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. The "standard" task is IMO one of the concepts in this step that actually *nobody* understands: I myself don't know what it means, and all the people I asked (when I presented the current scheme of installing the blends) have no idea what happens if they (de)select this. The help text in the tasks file (which is anyway not displayed in tasksel) does not help: f.e. if I want to use Debian for web browsing and e-mail, shall I install it? If I am a Java developer? The "standard" task itself is "obscure"; IMO even more than an "DebiChem" task (where already the name suggests that you don't need it if you are not interested in chemistry). > 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. So, if the average user doesn't have a glue about a Desktop environment, why is it offered in the installation by default? You seem to contradict to your own arguments here. In my opinion, the situation for the Debian Pure Blends is better here than for the Desktop environments: If a user doesn't know what the Blends mean, he just ignores it and doesn't install anything from it. This will cause no harm -- he will just not get something he anyway doesn't know about. But if a user doesn't understand what a "Desktop environment" is and therefore decides to not install it, he may left with an installation that he did not expect, and may have no chance to correct this without external help. Therefore it may be better to hide the desktop environment choice as well. > 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. > I personally don't have problems with changing this; however this would open again the discussion about the names -- IMO we should be consistent here. We can't call them "Specialized Installations" in the installer, but "Debian Pure Blends" on the web page. Renaming would have a tail of renaming it everywhere. So, I would propose to explain the name and the concept in the installer. There is already some text in the debian-blends-tasks.desc that would help to explain it -- it should just be displayed. Again, it would help much if tasksel would be able to display the help texts that are already there, and IMO if the programming efforts are limited, we would gain more in implementing help texts instead of separating the blends from the desktop environments. Best regards Ole
Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
On 18.05.2016 10:58, Petter Reinholdtsen wrote: > [Ole Streicher] >> In my opinion, the situation for the Debian Pure Blends is better here >> than for the Desktop environments: If a user doesn't know what the >> Blends mean, he just ignores it and doesn't install anything from it. > > An unskilled user do not ignore options he do not understand, he worries > and tries to understand them in order to avoid making a mistake that > will bother him in the future. If you believe options that are unknown > or confusing do not cause any harm, I am quite sure you are mistaken. > They increase the cognitive strain and force people to spend time trying > to understand that the option can be ignored. They also slow down the > installation process. Again, this questiones the whole tasksel step during the installation: As Christian points out, the majority of users doesn't understand what "Desktop Environment" means, especially if is should decide whether he needs "Cinnamon" or "Mate". My own experiences are that I don't know anyone who understands the "standard tools" item. Compared to that, "DebiChem" is understandable: That has something to do with chemistry. If the help would have been displayed, then he could also know it. He then could also understand what a "Pure Blend" is. It may help him to understand what a "Desktop environment" is. And maybe someone finds a smart help text for the "standard tools". If we really care that people should understand what they see, the first issue *should* be to implement the help texts here. > Note, I am not against the blends selection option during installation, > but believe it should be introduced after taking the negative effects as > well as the positive effects into account, not by claiming the negative > effects do not exist. I claim that they do not increase much. The issues are already there. > There exist usability research indicating that more than 7 options will > confuse the human brain and cause a lot of cognitive strain. To me it > tell us that we should avoid "just two screenfulls" of options, and > instead try to make sure at most one screenfull, and preferably less > than 7 options are presented in any dialog in the installer. This is already violated in some steps of the installation. And we already have 13 Blends; I don't see a good way to squeeze them into 7. Best regards Ole
Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
Hi Cyril, Am 21.05.2016 um 23:11 schrieb Cyril Brulebois: > so it would be nice to support all desc files shipped in tasksel-data > rather than hardcoding debian-tasks.desc when the --internal-tasks-only > flag is passed. If you want to do it in the way it was proposed some days ago (move the blends and the desktop choice into separate pages): You could use a "Section" keyword in the tasks header: this is already there for the structuration of tasks. Then the "main" task would just display everything without a section, and one option for each section (currently "Desktop Environment" and "Debian Pure Blends"). Enabling these options leads to follow-up screens showing their content. Aside from keeping the initial tasksel screen clean, this would also naturally remove the confusing checkboxes that are currently on the sections headers. Best regards Ole
Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
Hi Cyril, On 21.05.2016 22:58, Cyril Brulebois wrote: > I'm very much not happy with tasksel's picking up ", and I would very much > prefer if it > would only look at its own debian-tasks.desc when running from the > installer. Any objections? Just to clarify this, since I was the one who actually did and uploaded the change: It was not my intention to hijack the installation process. In some earlier mail on bug#758116, you mentioned that you cannot promise that you don't know if/when you have time to look into the integration of the Blends into the installer yourself [1]. For me, this sounds that we have to do it ourself if we want to get it in. And I tried it openly: The current solution was proposed in the bug#758116 [2], which was mirrored to debian-boot@l.d.o, and I asked explicitly for comments before the upload. Since no-one replied, I re-assigned the bug to src:blends (since this was the proposed place to actually fix it) and uploaded the new version with the package priority needed to get it into the basic system. I feel now a bit unhappy that there was no discussion about the topic before the upload, but I don't see what I could have done better (otherwise please give me a hint so that I can learn from it). However, as I said, that was not meant to be hijacking. If we find a better solution that does not need to include the debian-blends-tasks.desc, we can remove it. IMO it *is* however a good idea to keep tasksel using everything it finds in /usr/share/tasksel/descs/; this enables a relatively easy way to customize Debian here. Within Debian, we as a community should be able to find a solution that does not need to secure the installation process from "whatever people have managed to get into a basic system". Best regards Ole [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#220 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#240
