3 ms·

Two points to this: First, it's not without precedent. qmail's license prohibited binary redistribution (as well as modified source code distribution), and Deb

by danudey 11y ago

Two points to this: First, it's not without precedent. qmail's license prohibited binary redistribution (as well as modified source code distribution), and Debian's solution was packages that, as part of the install, patched, built, and installed qmail from sources on the target machine. Secondly, this is already an option. The ZFS on Linux project [0] provides packages which do exactly this, by: 1. Distributing kernel sources and building them against the currently install(ed) kernel(s) via dkms. This is actually a common mechanism for module distribution, and is also used by Virtualbox, or anyone else distributing kernel extensions, closed-source or not, which aren't included in the mainline kernel. 2. Providing the userspace binaries to interact with the custom-built ZFS kernel modules built on behalf of the user in #1. The difference here is Ubuntu distributing binary versions of the modules in the base install, which is important for things like installing on ZFS root, or accessing ZFS filesystems during install.

avar 11y ago
> It's not without precedent. [...] Debian's solution [for qmail] > was packages that, as part of the install, patched, built, and > installed qmail from sources on the target machine. I don't see how this is a relevant comparison in this context beyond the trivial "Debian has had some packages built from source at install time in the past". At the time qmail was shipped in Debian's non-free section, and the resulting binary wasn't being linked to a GPL codebase to get around linking clauses. So I can't see how this has anything to do with what's happening with ZFS here.
dbcurtis 11y ago
> modules in the base install, which is important for things like installing on ZFS root Ah yes, the bootstrapping problem.
- Dylan16807 11y ago
  An init script or the installer script could compile the module. Awkward but not hard. We can bootstrap much more difficult things. For example booting from kernel source: http://www.bellard.org/tcc/tccboot.html http://www.bellard.org/tcc/tccboot.html
ryao 11y ago
I am one of the ZoL developers. I assume that you are referring to the PPA and EL repositories. The ZoL PPA and EL repository maintainers use DKMS there because there is no way that a third party can ship kernel modules at the same time a distribution ships a new kernel. That means that there would always be a window of time where the new kernel is available and the modules are not, which breaks things. Furthermore, keeping up with new kernels from upstream to publish binary modules is a burden that DKMS eliminates. if it were not for those things, the upstream project repositories would have had binary modules available years ago. Since Canonical is in the position to avoid the race, they are able to ship the binary modules that the upstream project could not.

by danudey 11y ago

avar 11y ago

> It's not without precedent. [...] Debian's solution [for qmail] > was packages that, as part of the install, patched, built, and > installed qmail from sources on the target machine. I don't see how this is a relevant comparison in this context beyond the trivial "Debian has had some packages built from source at install time in the past". At the time qmail was shipped in Debian's non-free section, and the resulting binary wasn't being linked to a GPL codebase to get around linking clauses. So I can't see how this has anything to do with what's happening with ZFS here.

dbcurtis 11y ago

> modules in the base install, which is important for things like installing on ZFS root Ah yes, the bootstrapping problem.

Dylan16807 11y ago
An init script or the installer script could compile the module. Awkward but not hard. We can bootstrap much more difficult things. For example booting from kernel source: http://www.bellard.org/tcc/tccboot.html http://www.bellard.org/tcc/tccboot.html

ryao 11y ago

I am one of the ZoL developers. I assume that you are referring to the PPA and EL repositories. The ZoL PPA and EL repository maintainers use DKMS there because there is no way that a third party can ship kernel modules at the same time a distribution ships a new kernel. That means that there would always be a window of time where the new kernel is available and the modules are not, which breaks things. Furthermore, keeping up with new kernels from upstream to publish binary modules is a burden that DKMS eliminates. if it were not for those things, the upstream project repositories would have had binary modules available years ago. Since Canonical is in the position to avoid the race, they are able to ship the binary modules that the upstream project could not.