On jeu., 2016-03-24 at 08:29 +1000, Allan McRae wrote: > On 24/03/16 07:28, Sébastien Luttringer wrote: > > > > On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote: > > 1) No one support that we should manage kernels differently because they > > are under different repository. > > ==> We must manage them all the same way. > I did.
> > Maxime said building modules for only linux and linux-lts is a > good compromise. Maxime says exactly: "I feel that what Sebastien proposed, ie having built modules only for linux and linux-lts, and DKMS everywhere else would be a good compromise IMHO." Unfortunately, I never proposed linux-lts, it was you. So, I asked you the reason on IRC: [2016-03-21 20:32:47] <seblu> amcrae: why do you want to manage core kernels differently than others? And moreover, who cares of -lts nowdays? [2016-03-21 23:50:44] <amcrae> seblu: I don't want to manage core kernels different - preferably all kernels are provided with binary modules Reading this, and as you were behind the "core kernels" group, I was expecting you conclude to binary module for the arch kernel, dkms for the rest. Which is not coherent with the "we are a binary distro", but a common ground. > > 4) No one object to having dkms available for all modules; It's even > > supported > > by several fellows and this is offering support for AUR and custom kernels > > at > > almost no maintenance cost. > > ==> We must provides dkms build for all modules. Except those covered by 2. > As I said, no-one objected to DKMS modules. But no opinions were stated > whether they must be provided. I did, and Maxime: "I am somehow biased and in favor of DKMS everywhere" Florian: "Please go that route" (the route also refer to DKMS everywhere). Bartłomiej: "IMHO we should have DKMS for all external modules" Lukas: "I like the idea of having DKMS in the repo" > > 5) There is no much discussion about which should be the default (a binary > > flavor or dkms). I would propose a solution which let the user choose which > > module he want needs by pulling a defined dep like module-$modulename. > > ==> Applications should pull a generic deps to let users decide which > > module he > > wants (flavored or dkms). > REALLY? You need to read that thread again. Default binary was > strongly supported. Yes, binaries are preferred, that was not my point. The keyword was flavor. For example, vbox was pulling the binary modules for the -arch kernel by default, not the -lts one or others. As we don't have a way to select the correct kernel version I find more elegant to pull a virtual name which is provided. But like point 6 and 7, I feel you'll claim that is not part of the discussion. So, let's see that later. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
signature.asc
Description: This is a digitally signed message part
