[Recipients removed]
On Thu, Mar 05, 2026 at 07:36:47AM +0100, Cyril Brulebois wrote:
> > * Introduce a base package for udebs as well:
> > - Introduct linux-base.
> > - Rename kernel-image to linux-binary.
>
> As far as I can see, there are Provides left behind, so
> src:debian-installer should still build unchanged. Since there seem to
> be some moving pieces (a lot of things being shuffled around, also in
> the regular deb area), should we consider this to be the final situation
> and should we start updating dependencies on our end?
There are still some things left. Some might even affect the contents,
which might be incompatible changes.
What we should talk about is the organization of udebs and the sprawl of
them. And of course on the still used "let's just install additional
things from the linux debs".
What is still a plan is to uncouple the ABI in the package names from
the one used by the kernel itself. In deb land this is blocked by
missing support in apt, where I have to go again. In udeb land this is
no problem, as we have the Kernel-Version field in the Packages file.
And in udeb land we never have multiple versions installed. And I also
hope we don't rely on cruft for older versions to stick around for
stable.
For udebs this change could look like:
*-6.19.9-di -> *-forky-di (or *-deb14-di, as we have this elsewhere
already)
This is the kernel destined for forky, which is different then the one
destined for trixie (but the same for trixie-backports). In the end
this means the d-i build don't need to specify the actual version, but
only the generation it wants.
> I'm fine with waiting it out, especially if there's no immediate FTBFS.
It should not immediatelly fail, due to the Provides, yes.
Bastian
--
Yes, it is written. Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
