Jason Self <[email protected]> writes: > This seems to address my concern. My understanding is that Debian's > kernel packaging is available via > https://salsa.debian.org/kernel-team/linux > > So a strategy could be to "just" take the Linux-libre tarballs, add the > Debian bits, and compile. The only difference from a "normal" Debian > tarball is substituing one from fsfla.org instead of kernel.org. The > process could otherwise remain the same.
I think that approach will meet objections in the Debian community -- for any patches including security (for the kernel that happens once in a while, and getting patches out may be urgent), the team would then have to patch two source packages instead of one, keeping two repositories updated. While there are many examples of code duplication in Debian (think of all libz or other low-level duplication) there is a preference to not have code duplication, and duplicating >95% of the entire linux kernel code will be a hard sell. I think this has been one important concern why linux-libre isn't in Debian already. It isn't entirely unreasonable. I'm trying to explore the 'user-mode-linux' approach of adding a Debian package which takes the 'linux-source' Debian package as a Build-Depends, runs the deblob scripts, and build a kernel image. I am hoping this approach will be acceptable in the Debian community, and I see no fundamental reason why it shouldn't be -- the 'user-mode-linux' package has been in Debian for many years and is built in a similar way. It seems to me that such an end result may be identical to a linux-image-libre built directly from linux-libre source code. Which I find the most important thing to aim for in the Debian context. The method to get there can vary depending on circumstance. This is also similar to the Trisquel approach from what I can tell -- take the upstream Ubuntu kernel source package, runs a script on it and then build the result. The idea I'd like to pursue is to wrap that process up into a Debian source package properly, and ask for it to be included in Debian. > I think Alexandre Oliva did a good job explaining the future plan. > > With that plan in mind, and imagining the future state with the Linux- > libre git repository synchronized with upstream (Torvalds and -stable) > on a per-commit basis, cleaning commits as they happen rather than > running a deblob-<kver> script on a final tarball, the Linux-libre git > repo can stay mere minutes behind upstream. This allows for faster > releases and provides bleeding-edge versions for users who need them. > Eventually, this would mean the deblob-<kver> scripts are no longer > developed for new versions in favor of the pre-cleaned git repository > and resulting tarballs. > > My concern is whether the Debian kernel project project as had been > initially proposed could survive that shift. If this Debian kerenel > workflow is built around scripts that will eventually disappear, it > seems there's future breakage incorporated into the plan. Since the > clean git repository and tarballs are already available, why not base > the project on those sources now rather than "kicking the can down the > road"? It would be disappointing to choose a short-term strategy now > that forces a migration later, or maybe even ends the project entirely > if it can't survive the change, especially when the long-term solution > is already available to use the tarballs and git repository. I understand this concern, but Debian is tarball-centric and that is not going to change any time soon. And linux-libre is >95% same code as linux. So even if the deblob scripts will disappear, running a diff between the linux-libre tarball that you publish and the upstream linux kernel code, then applying that patch during build, will result in the same input source for the build process. So I think this approach of doing a "delta" package can continue to work even if the deblob scripts would disappear. /Simon
signature.asc
Description: PGP signature
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
