Your message dated Sat, 22 Apr 2017 15:51:16 +0200 with message-id <06fbeee5aa0d712149209bff5ce49e91@nefele.gnuservers.com.ar> and subject line Closing the bug with the resolution approved in February has caused the Debian Bug report #846002, regarding blends-tasks must not be priority:important to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: blends-tasks must be priority:standard and not make a mess out of tasksel menu
- From: Holger Levsen <holger@layer-acht.org>
- Date: Sun, 27 Nov 2016 17:38:27 +0100
- Message-id: <20161127163827.GA9964@layer-acht.org>
Source: blends Version: 0.6.94 Severity: serious Tags: d-i Justification: Policy 2.5 and breaking another package Hi, I'm sorry, but the current implementation of installing Blends from Debian images is simply not acceptable, as in, it completely breaks the UI of debian-installer thus the severity. (It's also an unacceptable policy violation, see below.) For those wondering what the current implementation looks like, have a look at https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png In words: several blends have been added to the tasksel menu (the one which asks which tasks should be installed, "default", "standard", "desktop", "ssh-server", etc.) The ascii version of the above linked screenshot looks like this: --begin-- At the moment, only the core of the system is installed. To tune the system to your needs, you can choose to install one or more of the following predefined collections of software. Choon software to install.' o webserver _ 0 printserver O SSHserver 0 standard system utilities O Debian Pure Blends o Deb; O. DebianEdu O. DebianEzGa O. DebianGames O. DebianGIS O. Hamradia O. DebianJunior O. DebianMed O. DebianMultimedia O ... Debian Science -- end -- This aint acceptable for a debian-installer for the reasons laid out in #758116. Look for those two mails from bubulle in that bug, they explain very well, that+why the current implementation is a *no go*: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#320 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#340 Technically this was implemented by setting the binary package blends-tasks to prio: important, which needs to be reverted to fix the current tasksel mess. Also, setting blends-tasks to priority:important is a policy violation, please read https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities - packages with priority:important are installed by default, and there is *no* need (as it doesnt make sense, it's not useful) to have blends-tasks installed by default on each and every Debian system. (I'm sorry if describing https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png as a mess hurts some people. I dont know a better way to put it.) So how to fix this *and* allow Debian blends be installed easily from official Debian media? My idea to implement official Debian which can be used to install blends is to introduce "flavors" (or spins or whatever, just a new term, to not overload old ones), which basically are themed netinstall images. For illustration, these are some netinstall image _flavors_/_spins_ I have in mind: debian-classic / textmode d-i debian-graphical installer blends selection (graphical) debian-edu blend (graphical) debian-parl blend (graphical) debian-speakup (textmode d-i with speech enabled by default) … The idea is, that these images have the *same features* (and packages), the differences are just which the preselected default in the boot menu. So they all have the same boot menu too, and it's possible to install each and every flavor by manually choosing a different boot menu. This has several benefits: - it's possible to tell people "download $this iso to install $this type of Debian" - without giving them congnitive stress by presenting them choices they dont understand - the boot menu is also not translatetable, so having choices there wont help many users. - this can be implemented for stretch. Major changes (especially ones requiring translations) are not likely to happen anymore, so this is one way to have official Debian blends images *at all*. (As said, the current implementation is not acceptable.) - the current implementation is also useless for Debian Edu and at least very inconvinient for other "non-standalone" blends (those who also need the desktop task to be installed), not all blends are self contained. Debian Edu OTOH is blend which comes in several variations. (see https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-stretch-manual-images/08-Choose_Debian_Edu_profile.png to understand that "one type of Debian Edu installs" is not enough.) The actual implementation of this will need to be done in debian-cd.git where the boot menu for netinst images is definied. For debian-edu it's probably enough to add a commandline parameter like this: preseed/early_command="anna-install debian-edu-profile-udeb" For blends-tasks it's probably enough to add a commandline parameter like this: preseed/late_command="apt install -y blends-tasks" (or probably better to turn blends-tasks into an udeb…) To track and implement this, I will clone this bug and reassign the clone to debian-cd (and then maybe file some more for some blends I care about). Actually, no, I will file a new bug using only half of the text of this bug :) I also plan to NMU blends-dev to set blends-tasks back to priority:optional, probably on Thursday or Friday this week. (To give some time to discussion, but soon, to not let this slip for to long.) - and I'll make this change in blends-dev.git right away. -- cheers, HolgerAttachment: signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
- To: 846002-done@bugs.debian.org
- Subject: Closing the bug with the resolution approved in February
- From: Margarita Manterola <marga@debian.org>
- Date: Sat, 22 Apr 2017 15:51:16 +0200
- Message-id: <06fbeee5aa0d712149209bff5ce49e91@nefele.gnuservers.com.ar>
- In-reply-to: <20170201215804.GA22769@localhost>
- References: <20170201215804.GA22769@localhost>
Hi,Let me first say that I'm sorry that we failed to act on this bug sooner.The resolution was voted and approved in early February but we failed to communicate this by closing this bug.We acknowledge that most of the contents of the resolution are obsolete by now, but we still wanted to publish this to be able to close this bug andmove on.We thank everyone that was involved in the discussion and hope that we canall work together towards making stretch a great release. ==== RESOLUTION ==== BackgroundThe blends-tasks package was uploaded in April 2016 setting its priority to important. The result of this change was that the package started getting automatically installed by debootstrap, with the intended effect of causing thelist of tasks shipped by the package to be displayed by tasksel in the debian-installer.Even though the debian-installer maintainer complained in May 2016 that he did not agree with this approach with regards to including external packages in thedefault tasksel screen, the important priority remains until today.In December 2016, changes were made in the tasksel package so that it no longerautomatically displays external tasks as part of the debian-installer.The current state is that chroots created by debootstrap in unstable or testing include the blends-tasks package, although the shipped tasks are not gettingdisplayed during the default installation.In #846002, the Technical Committee was asked by Holger Levsen to rule on the priority of the blends-tasks package. In the discussion that followed, the Committee was asked by Ole Streicher to additionally rule on whether the Blends selection should be part of the Debian Stretch installer and who should maintainthe list of options displayed to the user in the future.Using the power of the Technical Committee to make a decision when asked to doso (§6.1.3): 1. We acknowledge that the decision of which tasks to display duringinstallation falls within the jurisdiction of the debian-installer maintainers.2. In the Committee's opinion the use of important priority is not appropriate for the blends-tasks package according to the definition in the Debian policy (§2.5). As it was set only as a means to an end, and since it no longer doeswhat was intended, we recommend that this change gets reverted.3. We encourage the debian-installer maintainers to work together with other teams -including the blends-tasks maintainers- to provide useful and popularpackage selections through the debian-installer in future releases. ==== END OF RESOLUTION ==== -- Regards, Marga
--- End Message ---