Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89042 > unrolled thread

[RFC] Reorganizing Linux packages

Back to article view | Back to linux.debian.kernel

Contents

  [RFC] Reorganizing Linux packages Bastian Blank <waldi@debian.org> - 2025-08-30 13:20 +0200
    Re: [RFC] Reorganizing Linux packages Antonio Russo <aerusso@aerusso.net> - 2025-08-30 17:30 +0200
      Re: [RFC] Reorganizing Linux packages Bastian Blank <waldi@debian.org> - 2025-08-31 16:20 +0200
        Re: [RFC] Reorganizing Linux packages Antonio Russo <aerusso@aerusso.net> - 2025-08-31 16:30 +0200
      Re: [RFC] Reorganizing Linux packages Ben Hutchings <ben@decadent.org.uk> - 2025-09-08 20:40 +0200
    Re: [RFC] Reorganizing Linux packages Ben Hutchings <ben@decadent.org.uk> - 2025-09-08 22:20 +0200
      Re: [RFC] Reorganizing Linux packages Bastian Blank <waldi@debian.org> - 2025-09-27 14:20 +0200

#89042 — [RFC] Reorganizing Linux packages

[Cc apt maintainers, as this interacts with the versioned package
support, reply-to kernel maintainers]

Hi

This is the plan to re-organize the Linux packages a bit, or maybe a
lot.

The goals are:
- Move packaged files out of `/boot`
- Replace extra cloud build with stripped down variant of the normal
  build
- Prepare for pre-built initramfs and/or UKI
- Remove hard dependency between headers and (bootable) image

Does this look sensible?

Bastian

## Implementation

### Move files away from `/boot`

All the packages files are moved to `/usr/lib/modules/6.17-amd64`.
`linux-base` will include scripts to copy them to `/boot` and provide the
current interface for bootloaders.

### Split modules out of `linux-image` package

Like the other distributions we should move all the modules into it's own
package, `linux-modules`.  We can then split this new package further in a
later change.

### Replace extra cloud build with stripped down variant

We currently build a special config for cloud environments.  This comes with
some downsides, like we currently disable DRM and force traditional framebuffer
drivers.

This should be replaced with a stripped down version of the normale variant.
It should specify possitivly which modules and dependencies should be included,
without need to change the config.

Currently we use this extra variant for CI builds.  We need to find another way
to do CI builds without exploiding build times.  Like stripping almost all
modules from the build.

### Convert `linux-image` package into kind of meta-package

The `linux-image` packages are the interface for users to install.  We need to
retain it in the function of installing a bootable kernel.

The files itself can be moved into a different package `linux-binary`.

### Re-do dependencies in `linux-headers`

We want to fulfill the following conditions:
- `linux-image` and `linux-headers` can be installed independent.
- If both are installed, they need to be of the same version.
- This needs to apply both to the unversioned meta-packages and the versioned
  real ones.

This can be done by introducing a marker package, prior art is `gcc-14-base`.

### Fulfill current apt view on versioned kernel packages

apt includes code to not remove packages related to the current running kernel.
It is done by matching `uname -r` to the end of the package name.

This means, for out stipped down cloud variant, we need to rename packages to
fulfill this requirement.

Any communication regarding a more forgivable way have stalled in
https://bugs.debian.org/1060109.

## Side effects

- Images will get uninstallable until signed packages are available by default
- Closes way back to module signing via secure boot key
- Unsigned image is not longer installable in a booting configuration

## Proposed package layout

| Package: linux-base-6.17-amd64
| Depends:
|  linux-base (>= 1),
| 
| Package: linux-image-6.17-amd64
| Depends:
|  linux-binary-6.17-amd64 (= ${Source-Version}),
|  linux-modules-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-image-cloud-6.17-amd64
| Depends:
|  linux-binary-6.17-amd64 (= ${Source-Version}),
|  linux-modules-cloud-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-binary-6.17-amd64
| 
| Package: linux-binary-uki-6.17-amd64
| Provides:
|  linux-binary-6.17-amd64 (= ${Source-Version}),
| Breaks:
|  linux-binary-6.17-amd64,
| 
| Package: linux-binary-unsigned-6.17-amd64
| 
| Package: linux-modules-6.17-amd64
| Depends:
|  linux-base-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-modules-cloud-6.17-amd64
| Depends:
|  linux-base-6.17-amd64 (= ${Source-Version}),
| Provides:
|  linux-modules-6.17-amd64 (= ${Source-Version}),
| Breaks:
|  linux-modules-6.17-amd64,
| 
| Package: linux-headers-6.17-amd64
| Depends:
|  linux-base-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-base-amd64
| 
| Package: linux-image-amd64
| Depends:
|  linux-base-amd64 (= ${Source-Version}),
|  linux-image-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-image-cloud-amd64
| Depends:
|  linux-base-amd64 (= ${Source-Version}),
|  linux-image-cloud-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-headers-amd64
| Depends:
|  linux-base-amd64 (= ${Source-Version}),
|  linux-headers-6.17-amd64 (= ${Source-Version}),
| 
| Package: linux-headers-cloud-amd64
| Depends:
|  linux-headers-amd64 (= ${Source-Version}),
-- 
Well, Jim, I'm not much of an actor either.

[toc] | [next] | [standalone]

#89043

On 2025-08-30 05:00, Bastian Blank wrote:
> ## Side effects
> 
> - Images will get uninstallable until signed packages are available by default

I have been locally building the kernel modules package to distribute to ~dozen
computers.  I have so far only been able to build the -unsigned packages,
mostly because I have not gotten around to caring about building the signed images.

The changes here will certainly affect my build scripts for the kernel packages,
but I do think there should be a relatively simple pathway available for people
to build a new/different kernel using the debian packaging that integrates
nicely with the rest of Debian.

Maybe I just need to build the signed packages (Is that difficult? My
understanding that a second build process needs to happen with my own signing
key that would also need to be deployed to all of my machines to allow for
secure boot to be enabled.)  If that process is too difficult to describe
simply, maybe I'm asking to please not remove the ability to actually use the
unsigned images.

Thanks,
Antonio

[toc] | [prev] | [next] | [standalone]

#89052

On Sat, Aug 30, 2025 at 08:55:38AM -0600, Antonio Russo wrote:
> On 2025-08-30 05:00, Bastian Blank wrote:
> > - Images will get uninstallable until signed packages are available by default
> I have been locally building the kernel modules package to distribute to ~dozen
> computers.  I have so far only been able to build the -unsigned packages,
> mostly because I have not gotten around to caring about building the signed images.

I don't know what you mean.  To build modules, you need the
linux-headers-* packages.  The comment you quoted talks about
linux-image-*.

> The changes here will certainly affect my build scripts for the kernel packages,
> but I do think there should be a relatively simple pathway available for people
> to build a new/different kernel using the debian packaging that integrates
> nicely with the rest of Debian.

You can disable all the signing stuff if you can not make use of it.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

[toc] | [prev] | [next] | [standalone]

#89053

On 2025-08-31 08:00, Bastian Blank wrote:
> On Sat, Aug 30, 2025 at 08:55:38AM -0600, Antonio Russo wrote:
>> On 2025-08-30 05:00, Bastian Blank wrote:
>>> - Images will get uninstallable until signed packages are available by default
>> I have been locally building the kernel modules package to distribute to ~dozen
>> computers.  I have so far only been able to build the -unsigned packages,
>> mostly because I have not gotten around to caring about building the signed images.
> 
> I don't know what you mean.  To build modules, you need the
> linux-headers-* packages.  The comment you quoted talks about
> linux-image-*.

I'm very sorry---the word "module" should not have been in that sentence.  I have
built, for example,

linux-image-6.12.40+deb13-amd64-unsigned

that I used on these machines.  I do not use the `make deb` or whatever built-in
infrastructure exists that is shipped by upstream.  I am reusing almost all of the
Debian build structure to get something as close to Debian as possible (but with
more recent minor releases).

Best,
Antonio

[toc] | [prev] | [next] | [standalone]

#89131

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2025-08-30 at 08:55 -0600, Antonio Russo wrote:
[...]
> The changes here will certainly affect my build scripts for the kernel packages,
> but I do think there should be a relatively simple pathway available for people
> to build a new/different kernel using the debian packaging that integrates
> nicely with the rest of Debian.
> 
> Maybe I just need to build the signed packages (Is that difficult? My
> understanding that a second build process needs to happen with my own signing
> key that would also need to be deployed to all of my machines to allow for
> secure boot to be enabled.)

The signing is not particularly difficult; we use the script
<https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/debian-test-sign>
to do it in CI.  But deployment is indeed more complicated.

> If that process is too difficult to describe
> simply, maybe I'm asking to please not remove the ability to actually use the
> unsigned images.

Since Secure Boot is only supported on some architectures, there is per-
architecture configuration ("enabled_signed" in the "build" section) for
whether we build an "unsigned" package in preparation for signing, or
just build the final package directly.  You can override that in your
local build process.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

[toc] | [prev] | [next] | [standalone]

#89134

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2025-08-30 at 13:00 +0200, Bastian Blank wrote:
> [Cc apt maintainers, as this interacts with the versioned package
> support, reply-to kernel maintainers]
> 
> Hi
> 
> This is the plan to re-organize the Linux packages a bit, or maybe a
> lot.
> 
> The goals are:
> - Move packaged files out of `/boot`
> - Replace extra cloud build with stripped down variant of the normal
>   build
> - Prepare for pre-built initramfs and/or UKI
> - Remove hard dependency between headers and (bootable) image

I generally agree with these goals, but I would like to see how this is
done.

[...]
> ### Split modules out of `linux-image` package
> 
> Like the other distributions we should move all the modules into it's own
> package, `linux-modules`.  We can then split this new package further in a
> later change.

Let's not go too far with this.  Managing the current splitting of
modules into udebs already takes significant time (and seems to be
largely unnecessary).

> ### Replace extra cloud build with stripped down variant
> 
> We currently build a special config for cloud environments.  This comes with
> some downsides, like we currently disable DRM and force traditional framebuffer
> drivers.
> 
> This should be replaced with a stripped down version of the normale variant.
> It should specify possitivly which modules and dependencies should be included,
> without need to change the config.
> 
> Currently we use this extra variant for CI builds.  We need to find another way
> to do CI builds without exploiding build times.  Like stripping almost all
> modules from the build.

I like the fact that we do build a real configuration in CI builds, and
I would like to move forward to actually doing some boot testing of
that.  Introducing separate configurations for CI that would never be
used for real feels like a regression.

It seems like this would also result in it being possible to install
linux-{headers,image}-cloud-amd64 and then build an OOT module that
depends on an in-tree module that isn't installed.  Currnently this
problem would be detected at build time.

[...]
> ## Side effects
> 
> - Images will get uninstallable until signed packages are available by default

Can you expand on this?

> - Closes way back to module signing via secure boot key

I don't think that's a concern any more.

> - Unsigned image is not longer installable in a booting configuration
[...]

I think that's fine.  We would need to adjust some scripting, but I see
the current -unsigned packages as an internal detail that only confuses
users.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

[toc] | [prev] | [next] | [standalone]

#89424

On Mon, Sep 08, 2025 at 10:11:40PM +0200, Ben Hutchings wrote:
> On Sat, 2025-08-30 at 13:00 +0200, Bastian Blank wrote:
> > The goals are:
> > - Remove hard dependency between headers and (bootable) image
> I generally agree with these goals, but I would like to see how this is
> done.

This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1661

> > ### Split modules out of `linux-image` package
> > Like the other distributions we should move all the modules into it's own
> > package, `linux-modules`.  We can then split this new package further in a
> > later change.
> Let's not go too far with this.  Managing the current splitting of
> modules into udebs already takes significant time (and seems to be
> largely unnecessary).

This would be a two or three packages split, way less likely to break.

And for udebs we really should work with d-i and see if we can reduce
the package count by merging stuff.  We also are way less constraint
with size then ten years ago.

> > ### Replace extra cloud build with stripped down variant
> > Currently we use this extra variant for CI builds.  We need to find another way
> > to do CI builds without exploiding build times.  Like stripping almost all
> > modules from the build.
> I like the fact that we do build a real configuration in CI builds, and
> I would like to move forward to actually doing some boot testing of
> that.  Introducing separate configurations for CI that would never be
> used for real feels like a regression.

Well, at least we can see if it will boot in the configurations we
actually can test.  The cloud config as currently used is officially not
supported with anything we can just run, however sure it works.

With a CI config, we clearly tell that this config is only for tests and
nothing else.  And we currently have time problems with out CI builds
anyway.

> It seems like this would also result in it being possible to install
> linux-{headers,image}-cloud-amd64 and then build an OOT module that
> depends on an in-tree module that isn't installed.  Currnently this
> problem would be detected at build time.

Yes, Modules.symvers would contain modules that can't be directly used.
How do other distributions handle that?

> > ## Side effects
> > - Images will get uninstallable until signed packages are available by default
> Can you expand on this?

We will have a cross-source equal dependency between linux and
linux-signed for linux-image always.

linux-base-bla, linux-modules-bla comes from linux.
linux-image-bla comes from linux-signed and depends on linux-base-bla.

Bastian

-- 
Warp 7 -- It's a law we can live with.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web