The CD images include linux-headers packages, but d-i does not install
these by default. I think that it should, so that if the user needs
to build out of tree kernel modules they don't need to jump through
the additional hoops of learning that Debian has separated kernel
headers and how to install them. If we begin installing it by default,
users should come to just expect that they can build kernel modules from
source without doing anything more than a make, which will be a good
thing.

Which distributions *don't* do that?

Only if they also install a toolchain (whichever task that is).

This should also be done by installing the matching metapackage
(linux-headers-<flavour>) rather than the ABI-specific package.

Ben.

Which distro does? A normal user does not need to build its own modules.
We also don't install a toolchain, aka build-essential.

Bastian

Joey Hess <joeyh@debian.org> writes:

Really?  I seriously doubt that.  It's about as good as making it easier
for the users to replace the default libc or init system with a non-
Debian package.


Bjørn

Bjørn Mork wrote:

I have never needed to replace libc in order to make my laptop's wifi
work.

I agree with Joey here. Imho gcc & linux-headers should be installed
by default when a desktop-like installation/tasks are chosen.

My latest ultra notebook doesn't have ethernet port and needs
out-of-the-tree wifi drivers compiled.
I fetched the tarball off github on my phone & transferred it to that
notebook over USB and then compiled.
I managed to compiled because I joyfully discovered that default
Ubuntu installations do install gcc and linux-headers unconditionally.
This was my first time experience where drivers didn't work and I
really had no other connectivity options, which I discovered only
after completing the installation.

Regards,

Dmitrijs.

I agree with Joey here. Imho gcc & linux-headers should be installed
by default when a desktop-like installation/tasks are chosen.

My latest ultra notebook doesn't have ethernet port and needs
out-of-the-tree wifi drivers compiled.
I fetched the tarball off github on my phone & transferred it to that
notebook over USB and then compiled.
I managed to compiled because I joyfully discovered that default
Ubuntu installations do install gcc and linux-headers unconditionally.
This was my first time experience where drivers didn't work and I
really had no other connectivity options, which I discovered only
after completing the installation.

Regards,

Dmitrijs.

Dmitrijs Ledkovs <xnox@debian.org> writes:

And this is the preferred solution, which you would recommend to any new
user?  How about having the wifi device support by Debian instead?
Wouldn't that be better?


Bjørn

Dmitrijs Ledkovs wrote:

Noticing a "this laptop worked for me on Ubuntu" page that treated
installing necessary out of kernel modules as (rightly) no big deal, and
comparing it to general experiences with it being a PITA in a similar
situation with Debian was part of my reason for concluding this should
be done.

Note that if the user installed Debian from a USB stick with no network,
they are left with an apt configuration that does not allow apt-get
install to work after the installation even if the USB stick is plugged
in. This would be nice to fix in general, but leaving the user with
everything they are going to need to get a network connection
pre-installed is a reasonable workaround for d-i to make.

It may make sense to only do it if d-i detects there is no network. At
least lack of networking is the most annoying case. This would also give
it a rationalle for installing make and gcc.

(IIRC discover already installs this stuff if it detects hardware
that is supported by out of tree modules packaged in Debian, which it
automatically builds from source.)

Sure, but there will always be hardware which is not supported out of
the box by stable debian release.
My wifi driver is on it's way and will land in either 3.12 or 3.13 kernels.
Of course it's not the preferred solution, but rather a fall-back
resort that Debian thought of, and not simply ignored.

Regards,

Dmitrijs.

Quoting Bjørn Mork (bjorn@mork.no):

I'm sorry to play this game, but have you noticed who sent this bug report?

Then, have you ever looked at the changelog of any D-I package?


In short, if Joey if doing this suggestion, I would be tempted to give
him a bit of credit for having good reasons to do it. Ha gave a few in
the bug report rationale as well as in the thread that happned just
befor ehe reported the bug.

It's quite some time  since I hadn't to build out-of-tree modules for
hardware support but my understanding is that this is made fairly easy
by a few tools *assuming one has a toolchain and the Linux kernel
headers installed*.

So, it's probably less overkill than it may seem at first glance to
imagine that installing headers by default may help in some cases.

Christian PERRIER <bubulle@debian.org> writes:

Yes, which is all the more reason to expect a proper bug report.

Yes, it is easy. But so should installing additional, non-default,
packages be.  If it's not, then that's a real installer bug.  (never
mind lack of networking - the initial install had to use some sort of
medium)

I hope and expect most Linux users never needing kernel headers.  And if
they do need them, then the headers should be pulled in by one of the
-dkms packages.  I do not think it is a good idea to encourage users or
driver authors to keep drivers out of Debian.


Bjørn

How does the dependency look like to get headers for the _currently_
running kernel and not the latest one available/installed?
Considering I can upgrade to the new kernel packages a few times
before rebooting.

Regards,

Dmitrijs.

Dmitrijs Ledkovs <xnox@debian.org> writes:

This is way outside what you can expect to be supported.

Sitting on the outside here, I am puzzled to see this belief that Debian
should support all sorts of user modifications to the kernel package.
Sure, I appreciate the fact that it is easy to modify any package, using
old packages long gone, or installing software from a 3rd party.  I do
all three.  But I don't expect anyone to support these modifications.

And if there is some kernel module missing, then my experience is that
the excellent Debian kernel team is more than happy to add it.  Sending
a bug report with a patch or a list of mainline git commits is actually
easier than remembering to rebuild your out-of-three module on every
kernel upgrade.  This is what Debian users should be pointed to.  Not a
howto telling you to build some strange driver from untrusted sources
yourself.  That's just crazy.

Still, I do appreciate the freedom to do crazy stuff.  But I react on
the demands that it should be easier, because *any* level of support can
be seen as an OK from Debian.  And using random out-of-tree drivers is
definitely not OK in general.


Bjørn

I wouldn't worry about that.  Users likely want to be using the latest
kernel anyway, and if they for some reason aren't and submit a bug
report about modules not working, they can be instructed to either
reboot or install the linux-headers for their specific kernel version.

This isn't at all about modifying the kernel package itself.  It is
about building kernel modules available in many separate packages.

Best wishes,
Mike