Paul Wise <p...@debian.org> writes: > On Mon, Dec 4, 2017 at 6:43 AM, Bjørn Mork wrote: > >> But how would a user without any previous knowledge of modemmanager or >> Linux networking be able to figure this out? > > It sounds like you are looking for isenkram to be integrated into the > installer so that the knowledge of which package maps to which > hardware is available to the user when doing an install and for > modemmanager to declare which devices it supports via AppStream and > for installing modemmanager to pull in networkmanager and remove wicd: > > https://tracker.debian.org/pkg/isenkram > http://people.skolelinux.org/pere/blog/tags/isenkram/ > https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware
No, not really. I want the installation to end up with a *more* predictable set of packages. Attempting to do any sort of harware based package selection will result in less predictability. This is support hell. Imagine a Debian user trying to assist another Debian user. If you can't even establish a package set baseline, then where do you start? No, I definitely don't want some magic guessing of what packages I need. I want the default install to include a large enough set of packages supporting as many use cases as reasonable. If there are more than one alternative package providing a given service, then the default should be the one supporting most use cases. At least if there is little or no doubt. Which I believe covers the wicd vs NM case. Hardware detection during installation will also fail for common use cases like plugging in a USB modem after installation. My example had a built-in modem, but it could just as well be an external one. And even if this example was related to hardware enablement, that is only part of the problem. Replacing any core system package with something other users won't consider "default" is going to cause confusion. I guess the definition of "core system package" is something which can be discussed. But it is a fact that all the DEs come with their own set of system daemons, libraries and tools. Take it to the extreme and you end up with the kernel being the only shared package between two different DE installations. I just realized that this might appear as if I am opposing choice. That is not my intention. What I am trying to say is that I found the results of the task selection confusing, because it wasn't clear to me that I was actually choosing a different Debian derivative by selecting one of the desktop tasks. If you are going to continue to provide these variants, then it would have been better (for me at least) if every task was packaged as a separate installer image. This would also reduce the number of necessary questions during install. Bjørn
