Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
Hi Phil, On 10.12.2016 01:03, Philip Hands wrote: > Just to test things out, if one adds: > > url=hands.com/d-i/bug/846002/preseed.cfg > > to the kernel command line (so, hitting TAB as the installer's boot menu) > it will tweaks d-i to have such a menu. To me, this looks like a very nice solution! In the tasksel screen, the "back" button was enabled for the first time, but produced an error and brought me back to the list of installation steps. Going through the sofware selection a second time made the back button disappear. I have absolutely no experience with preseeding, so I can't test it more than the interactive use case. The advantage of your solution is that one doesn't need to touch tasksel itself, which may address Cyrils doubts. And since Holger also seems to be happy with this solution: maybe we could focus on this in the further discussion? Best regards Ole
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
Ole Streicher writes: > Hi Phil, > > On 10.12.2016 01:03, Philip Hands wrote: >> Just to test things out, if one adds: >> >> url=hands.com/d-i/bug/846002/preseed.cfg >> >> to the kernel command line (so, hitting TAB as the installer's boot menu) >> it will tweaks d-i to have such a menu. > > To me, this looks like a very nice solution! In the tasksel screen, the > "back" button was enabled for the first time, but produced an error and > brought me back to the list of installation steps. > > Going through the sofware selection a second time made the back button > disappear. I have absolutely no experience with preseeding, so I can't > test it more than the interactive use case. Thanks for testing that, and don't worry about the preseeding bit. It's far from straight-forward, even for people that know what they're doing. I agree that the back buttons don't work (and should do, so that one can glance at tasksel and realise that you should bail out and select a simple option). I think it will need to be put into the scripts in tasksel itself to fix that, which will also remove the bits of the script that I'm unhapy about anyway (chrooting to set preseeds). That being the case, there's not much point testing with preseeding, as it's not going to be implemented like this, so this should just be considered a demonstration for now. Anyway, having done it, my first impression (which I'm surprised by) is that the list is too short -- I think that it is perhaps because it is much easier to select one option from a list than it is to decide what combination of options one wants. How about one or both of: bare-bones -- nothing selected minimal-server -- ssh and nothing else Is there any objective way of working out what other combinations would be popular, rather than just guessing? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#846002: blends-tasks must not be priority:important
While I have no opninion on whether blend-tasks is important enough to have installed by default, I would urge to revisit the idea to (mis)use the package priority to achieve that. If a package was pulled in by debootstrap because of its priority, it's marked as manually installed. This is usually bad, because say later on you decide that you want to change the name of the package or implement this differently, the manually installed package sticks around. So, assuming blend-tasks is important enough to be installed by default, please think of another way to pull it in. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
Hi Phil, On 10.12.2016 12:06, Philip Hands wrote: > Anyway, having done it, my first impression (which I'm surprised by) is > that the list is too short -- I think that it is perhaps because it is > much easier to select one option from a list than it is to decide what > combination of options one wants. My feeling is exactly the opposite: the having the two most prominent options there is (if they have good names), with the "90% standard" preselected seems simple enough; in the discussion of this bug there was even the proposal (as I remember) to have just *one* option, which also would not be too bad: Most people probably don't care here anyway to select something, and just having *one* checkbox here would give room for a detailed explanation what is going to be installed then. Then, even the "server" would move to the "extended" selection -- servers are usually installed by more experienced users which can deal with more options. In any case, I would like to hear the opinion of Cyril or other d-i people here. Best regards Ole
Bug#846002: blends-tasks must not be priority:important
Hi Michael, On 10.12.2016 13:18, Michael Biebl wrote: > While I have no opninion on whether blend-tasks is important enough to > have installed by default, I would urge to revisit the idea to (mis)use > the package priority to achieve that. That is the standard way how tasksel gets its menu: tasksel-data is marked as "important" and that way it finds its way onto the installer image. So, all arguments you have here are also valid for the default tasks. If we think this is wrong, we should get a completely different solution here -- which is IMO outside of the scope of this bug. > If a package was pulled in by debootstrap because of its priority, it's > marked as manually installed. > This is usually bad, because say later on you decide that you want to > change the name of the package or implement this differently, the > manually installed package sticks around. But this problem is true for all manually installed package, right? So, a manually installed iceweasel would have a renaming problem as well. Couldn't it be solved by a transitional package? I would also consider this as not being release critical. The current solution would also have the advantage that people who actually hate the blends task list (like Holger Levsen: "I will get used to type 'apt remove blends-tasks' as well.") have the possibility to remove that from the tasks selection list. So, this would probably have more acceptance than a solution where the blends tasks are glued into the main task selection. Best regards Ole
Bug#846002: blends-tasks must not be priority:important
Am 10.12.2016 um 14:15 schrieb Ole Streicher: > Hi Michael, > > On 10.12.2016 13:18, Michael Biebl wrote: >> While I have no opninion on whether blend-tasks is important enough to >> have installed by default, I would urge to revisit the idea to (mis)use >> the package priority to achieve that. > > That is the standard way how tasksel gets its menu: tasksel-data is > marked as "important" and that way it finds its way onto the installer > image. So, all arguments you have here are also valid for the default > tasks. If we think this is wrong, we should get a completely different > solution here -- which is IMO outside of the scope of this bug. Well, two wrongs don't make one right. An obvious solution seemed to me, to make tasksel(-*) depend on blends-tasks. This why, the package would be marked as auto-installed, and should you later decide to implement that differently, say directly in tasksel, then tasksel can simply drop that dependency. I assume though you have considered this obvious solution and decided against it for some reason? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#846002: blends-tasks must not be priority:important
Hi Michael, On 10.12.2016 14:48, Michael Biebl wrote: > Am 10.12.2016 um 14:15 schrieb Ole Streicher: >> Hi Michael, >> >> On 10.12.2016 13:18, Michael Biebl wrote: >>> While I have no opninion on whether blend-tasks is important enough to >>> have installed by default, I would urge to revisit the idea to (mis)use >>> the package priority to achieve that. >> >> That is the standard way how tasksel gets its menu: tasksel-data is >> marked as "important" and that way it finds its way onto the installer >> image. So, all arguments you have here are also valid for the default >> tasks. If we think this is wrong, we should get a completely different >> solution here -- which is IMO outside of the scope of this bug. > > Well, two wrongs don't make one right. If we would remove one of them, the other would still stay there, and the problem remains. > An obvious solution seemed to me, to make tasksel(-*) depend on > blends-tasks. This why, the package would be marked as auto-installed, > and should you later decide to implement that differently, say directly > in tasksel, then tasksel can simply drop that dependency. The disadvantage is that people can't uninstall the blends task. And at least Holger clearly indicated that he wants to have this option. > I assume though you have considered this obvious solution and decided > against it for some reason? The major reason is that during the discussion of the blends into tasksel became clear that the tasksel maintainers are already overloaded. Having to manage the blends tasks here would put another work on top of that. Additionally, they have no competence in deciding neither which blends should go in, nor about how to describe them. This all done by the Blends team. So, it seems to be natural for me to have the blends tasks maintained by this team, and not by the tasksel developers. In principle, the same would be applicable for the desktop selection, however there seems to be no dedicated team for the desktop. Best regards Ole
Bug#846002: blends-tasks must not be priority:important
Hi again, sorry: missed one point: On 10.12.2016 15:07, Ole Streicher wrote: > On 10.12.2016 14:48, Michael Biebl wrote: >> An obvious solution seemed to me, to make tasksel(-*) depend on >> blends-tasks. This why, the package would be marked as auto-installed, >> and should you later decide to implement that differently, say directly >> in tasksel, then tasksel can simply drop that dependency. >> I assume though you have considered this obvious solution and decided >> against it for some reason? If you mean here why we just didn't put blends-tasks as dependency into tasksel-data: this wouldn't help, since the Policy says (§2.5): "Packages must not depend on packages with lower priority values" Since tasksel-data is Priority: important, blends-tasks would need to have this priority as well. Ole
Bug#846002: blends-tasks must not be priority:important
Am 10.12.2016 um 15:20 schrieb Ole Streicher: > If you mean here why we just didn't put blends-tasks as dependency into > tasksel-data: this wouldn't help, since the Policy says (§2.5): > > "Packages must not depend on packages with lower priority values" > > Since tasksel-data is Priority: important, blends-tasks would need to > have this priority as well. That part of the policy is non-sense and thankfully is in the process of being fixed [1]. Library and helper packages should never be installed because of their priority imho. I deliberately violate that policy in various packages, fwiw. Regards, Michael [I'll stop here since I don't want to derail the discussion to much, just wanted to give my 2¢] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote: > How about one or both of: > > bare-bones -- nothing selected > minimal-server -- ssh and nothing else > > Is there any objective way of working out what other combinations would > be popular, rather than just guessing? Note that the whole point of tasksel was, originally, to show just that. Things have simply gotten out of hand. If you're going to update tasksel, it might be good to keep that in mind... -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
