> whatever steps would be needed to transform linux-source into a > linux-libre source tree (whether that be a deblob script or some > successor), it must not be applied to a newer version of linux-source > than what it was designed to work with. Perhaps this is where some of > Jason's reservations are coming from
To be sure my concern was different which I'll explain below. > Maybe we could use the Linux-libre tarball in a way that's fine for > Debian: maybe we can use real linux-libre tarballs and move the > Debian bits (including patches) over. The resulting source tree ought > to be basically the same. > In summary, I think Debian has the tooling—even if it's lesser-known > and requires some more esoteric tricks—to do this right. I will do > some serious thinking about how I can help. 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 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
