[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Out-of-tree kernel module udeb



On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Aron Xu <aron@debian.org> (2015-05-17):
> > [Not on list, please keep me posted.]
> 
> [done]
> 
> > I'm wondering whether d-i team would like to accept out-of-tree kernel
> > module udeb for certain features, for example ZFS support? And if the
> > answer is yes, what's the best way of doing it?
> 
> I wasn't actively involved with debian-boot back then but from what I've
> seen through debian-release at the time, o-o-t modules were a huge pain
> to handle. I'd rather not have to deal with such things again.
> 
> > Two years ago we had a GSoC project to provide ZFS on Linux
> > integration, and after that licensing problem blocked the code's
> > actual inclusion. As written in one of the recent Bits from the DPL,
> > the issue is in much better shape and I believe it's time to discuss
> > how to move on with the technical part.

This is wishful thinking.

> > At the moment only spl is available in the archive, using dkms, and
> > for zfs it's similar in the way of packaging though not uploaded yet.
> > What we have (code ready to go) is a mechanism that detects/gets
> > definition of a current KVERS and generate a source package with
> > dependencies and binary packages with names corresponding to it.
> > 
> > What do you guys think?
> 
> My personal stance on kernel related things would be “upstream first”.
> If it ain't going to be merged into mainline, or at least accepted as a
> patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure
> we want to support that.
> 
> Cc-ing debian-kernel@ to see what they think.

I strongly oppose adding OOT modules this way as a supposed workaround
for licence incompatibility.

For OOT modules that are under GPLv2 or compatible licence, you would
have to decide which images they belong in rather than letting the
kernel team do that through kernel-wedge config.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: