Linux Libre in Debian

[Simon Josefsson]

Jason Self <j at jxself.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251209/a7fbb30c/attachment.sig>