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

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

Meta packages for modules

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

Contents

  Meta packages for modules Bastian Blank <waldi@debian.org> - 2026-08-10 10:40 +0200
    Re: Meta packages for modules Ben Hutchings <ben@decadent.org.uk> - 2026-09-23 20:10 +0200
      Re: Meta packages for modules Bastian Blank <waldi@debian.org> - 2026-09-23 20:50 +0200

#93652 — Meta packages for modules

Hi

Some time ago, we split the modules into it's own package.
One goal stated at that time was the possibility to convert the current cloud build into a stripped down version of the normal build.
But what we did not talk about was how to actually make it usable.

My initial idea was to copy what we currently have: One image package for default and another for cloud.
This works, but if we want to introduce UKI as separate package, we now have 4 (2*2) image packages.
This will fix this one problem, but make other things impossible.

One of my secondary goals, not sure how possible they are within Debian, is to split away rarely used modules, like most other distributions now do as well.
This however now requires another image package to pull this in.

So I propose that we also introduce meta packages for the modules.
This way we can offer the same guarantees then with the headers packages:
- All versioned packages are of the same version
- All meta packages are of the same version (and with it all the versioned packages for this version)

Users can select which modules package they want: the default one or the cloud one, just by installing the corresponding meta package.
They can also opt-in into the extra modules by installing this separate meta package.
All packages are kept in sync by the base dependency.

The package linux-image-cloud-amd64 is kept for correct upgrades.

Bastian

## Proposed package layout
```
Package: linux-image-7.2-amd64
Depends:
 linux-binary-7.2-amd64 (= ${Source-Version}),
 linux-modules-7.2-amd64 (= ${Source-Version}) | linux-modules-main-7.2-amd64 (= ${Source-Version}),

Package: linux-image-amd64
Depends:
 linux-base-amd64 (= ${Source-Version}),
 linux-image-7.2-amd64 (= ${Source-Version}),
 linux-modules-amd64 (= ${Source-Version}) | linux-modules-main-amd64 (= ${Source-Version}),

Package: linux-image-cloud-amd64
Depends:
 linux-base-amd64 (= ${Source-Version}),
 linux-image-7.2-amd64 (= ${Source-Version}),
 linux-modules-cloud-amd64 (= ${Source-Version})

Package: linux-modules-7.2-amd64
Depends:
 linux-base-7.2-amd64 (= ${Source-Version}),
Provides:
 linux-modules-main-7.2-amd64 (= ${Source-Version}),
Conflicts:
 linux-modules-main-7.2-amd64,
Replaces:
 linux-modules-main-7.2-amd64,

Package: linux-modules-cloud-7.2-amd64
Depends:
 linux-base-7.2-amd64 (= ${Source-Version}),
Provides:
 linux-modules-main-7.2-amd64 (= ${Source-Version}),
Conflicts:
 linux-modules-main-7.2-amd64,
Replaces:
 linux-modules-main-7.2-amd64,

Package: linux-modules-extra-7.2-amd64
Depends:
 linux-base-7.2-amd64 (= ${Source-Version}),
 linux-modules-7.2-amd64 (= ${Source-Version}).

Package: linux-modules-amd64
Depends:
 linux-base-amd64 (= ${Source-Version}),
 linux-modules-6.17-amd64 (= ${Source-Version}),
Provides:
 linux-modules-main-amd64 (= ${Source-Version}),
Conflicts:
 linux-modules-main-amd64,
Replaces:
 linux-modules-main-amd64,

Package: linux-modules-cloud-amd64
Depends:
 linux-base-amd64 (= ${Source-Version}),
 linux-modules-7.2-cloud-amd64 (= ${Source-Version}),
Provides:
 linux-modules-main-amd64 (= ${Source-Version}),
Conflicts:
 linux-modules-main-amd64,
Replaces:
 linux-modules-main-amd64,

Package: linux-modules-extra-amd64
Depends:
 linux-base-amd64 (= ${Source-Version}),
 linux-modules-7.2-extra-amd64 (= ${Source-Version}),
```
-- 
Phasers locked on target, Captain.

[toc] | [next] | [standalone]

#94191

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

On Mon, 2026-08-10 at 10:13 +0200, Bastian Blank wrote:
[...]
> One of my secondary goals, not sure how possible they are within Debian, is to split away rarely used modules, like most other distributions now do as well.
> This however now requires another image package to pull this in.
> 
> So I propose that we also introduce meta packages for the modules.
> This way we can offer the same guarantees then with the headers packages:
> - All versioned packages are of the same version
> - All meta packages are of the same version (and with it all the versioned packages for this version)
> 
> Users can select which modules package they want: the default one or the cloud one, just by installing the corresponding meta package.

But modules are duplicated between those, right?

> They can also opt-in into the extra modules by installing this separate meta package.

Do you plan to extend kernel-wedge to do that, or are you thinking of
something a bit simpler?

> All packages are kept in sync by the base dependency.
> 
> The package linux-image-cloud-amd64 is kept for correct upgrades.
> 
> Bastian
> 
> ## Proposed package layout
> ```
> Package: linux-image-7.2-amd64
> Depends:
>  linux-binary-7.2-amd64 (= ${Source-Version}),
>  linux-modules-7.2-amd64 (= ${Source-Version}) | linux-modules-main-7.2-amd64 (= ${Source-Version}),
> 
> Package: linux-image-amd64
> Depends:
>  linux-base-amd64 (= ${Source-Version}),
>  linux-image-7.2-amd64 (= ${Source-Version}),
>  linux-modules-amd64 (= ${Source-Version}) | linux-modules-main-amd64 (= ${Source-Version}),
> 
> Package: linux-image-cloud-amd64
> Depends:
>  linux-base-amd64 (= ${Source-Version}),
>  linux-image-7.2-amd64 (= ${Source-Version}),
>  linux-modules-cloud-amd64 (= ${Source-Version})
> 
> Package: linux-modules-7.2-amd64
> Depends:
>  linux-base-7.2-amd64 (= ${Source-Version}),
> Provides:
>  linux-modules-main-7.2-amd64 (= ${Source-Version}),
> Conflicts:
>  linux-modules-main-7.2-amd64,
> Replaces:
>  linux-modules-main-7.2-amd64,
> 
> Package: linux-modules-cloud-7.2-amd64
> Depends:
>  linux-base-7.2-amd64 (= ${Source-Version}),
> Provides:
>  linux-modules-main-7.2-amd64 (= ${Source-Version}),
> Conflicts:
>  linux-modules-main-7.2-amd64,
> Replaces:
>  linux-modules-main-7.2-amd64,
[...]

I think the virtual packages make this unnecessarily confusing.  To me,
linux-modules-7.2-amd64, as the default modules package for 7.2-amd64,
would also be seen as the "main" modules package.  Why not use only the
real package names?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

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

#94192

On Wed, Sep 23, 2026 at 08:01:35PM +0200, Ben Hutchings wrote:
> > Users can select which modules package they want: the default one or the cloud one, just by installing the corresponding meta package.
> But modules are duplicated between those, right?

For now they will be duplicated.  We can change that later.

> > They can also opt-in into the extra modules by installing this separate meta package.
> Do you plan to extend kernel-wedge to do that, or are you thinking of
> something a bit simpler?

I have an alternative implementation that fits better in the existing
stuff.  I intend to also use that for udebs later, but need to figure
out the caveats first.

The current unfinished state can be found here:

https://salsa.debian.org/waldi/linux/-/commits/modules-split?ref_type=heads

> I think the virtual packages make this unnecessarily confusing.  To me,
> linux-modules-7.2-amd64, as the default modules package for 7.2-amd64,
> would also be seen as the "main" modules package.  Why not use only the
> real package names?

Yes, that would work as well.

Bastian

-- 
It is a human characteristic to love little animals, especially if
they're attractive in some way.
		-- McCoy, "The Trouble with Tribbles", stardate 4525.6

[toc] | [prev] | [standalone]

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

csiph-web