Re: Should tasks be considered harmful?
On Mon, Dec 4, 2017 at 9:18 PM, Bjørn Mork wrote:
> 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.
Understood.
> 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?
There is already the possibility of different package sets, people can
install different desktops or even no desktop using d-i. They can also
add or remove packages after the installation is complete.
> 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.
That seems reasonable, I guess you should then file a bug against any
tasks that depend on wicd and ask them to switch to NM, but see Jonas'
response.
OTOH the number of use-cases supported by Debian is high.
Does everyone need to access NTFS/HFS+ filesystems?
Does everyone need to access iOS devices?
Does everyone need to interact with LEGO devices?
Does everyone need the app for firing foam missile launchers?
> 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.
isenkram was primarily developed for the use-case of plugging in
devices and then getting the appropriate software installed and the
device working, my suggestion of adding isenkram to the installer was
primarily so that devices plugged in at install time will always work
on first boot. So isenkram could be both in the installer and in the
installed system.
> 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.
Debian hasn't yet defined any immutable "standard systems", it might
be interesting to do that and put them in ostree like Endless are
doing:
https://debconf17.debconf.org/talks/41/
That would require some repacking of "apps" .deb files into Flatpaks.
https://debconf17.debconf.org/talks/59/
It is definitely true that each desktop reinvents a lot of wheels, but
some things (like libsecret or gnome-shell or GTK+ or Qt) are shared
between some of them.
> 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.
The Debian installer doesn't install any Debian derivatives (like
Ubuntu), it only installs subsets of the whole of Debian, but I assume
that "subset" is what you meant by "derivative".
To a small extent the different tasks are already packaged as
different installer images, there is an Xfce installer CD.
> This would also reduce the number of necessary questions during install.
This is probably a good thing for new users.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: