Re: Upcoming changes to Debian Linux kernel packages

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.

Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?

I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.

Let me see if I understand what you are saying.

1)  kernel headers will be removed from the archive.  So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.

2) If the kernel header version changes but the kernel header package
name does not change  (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.

3) you can run into trouble between testing and backports.

I think that's what you mean by the first-level error.
If not, I'm still confused.

In the second level error case you are talking about is:

1) there is a regression in the kernel

2) someone needs kernel headers for an old kernel they want to downgrade
to.

I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and  the
downgrade appears to follow naturally from that.

You point out that someone may not be able to get kernel headers for the
downgraded kernel.

a) They might.  In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing  there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.

B) They might already have headers installed.  Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.

I think what you are saying is that

1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.

2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.

And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.


Bastian> -- Each kiss is as the first.  -- Miramanee, Kirk's wife,
Bastian> "The Paradise Syndrome", stardate 4842.6

Re: Upcoming changes to Debian Linux kernel packages

[Russ Allbery]

Sam Hartman  writes:

> B) They might already have headers installed.  Imagine someone who
> installs headers at the same time they install the kernel.  Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers.  They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.

I am also really confused by this discussion and don't entirely understand
the motivation for the proposed change to kernel headers, but isn't the
situation Sam describes above the normal way Linux kernel headers work and
have worked for years?  Kernels come with headers matching the same
version, if you want headers for external modules you install both
packages at the same time via one mechanism or another, and you only
remove the kernel and headers when you're pretty sure you will never use
that kernel again.

When I was using external modules heavily, I routinely kept three or four
old kernels and their corresponding headers installed at the same time so
that I could easily downgrade if I ran into regressions without having to
track down old packages that may have been removed from the archive.  This
feels like a normal and somewhat obvious Debian systems administration
thing to do to me.

I realize in the new signing regime every new kernel would have a separate
headers package (as opposed to today where the kernel and headers are
updated in place with the same package name if there is no ABI change),
but to me this doesn't feel like a significant difference for users.  I
haven't been paying close attention, so maybe I'm wrong, but I feel like
most kernel package updates have been ABI updates anyway, particularly in
stable.

-- 
Russ Allbery (r...@debian.org)  

Debian 12 non graphical installation; partitioning in MB/GB

[Andrei Enshin]

Hello,

I'm installing Debian and specified 1024MB for the primary partition
(since I do it on a virtual box it doesn't give me any choices, so it
is MBR).

After installation it seems to be MB is not MiB which might be logical
however the installer interface tells me it is exactly one 1GB.

When I do specify 1000 MB - it says 999.3MB.

So it seems there is inconsistency in two different screens in MB.

May you confirm it is and if so, I can try to file a bug and even try
to work on a fix if it is not hard.

-- 
Best Regards,
Andrei Enshin

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.

We could encode that in the upstream version.  Aka to have
co-installable packages for security updates we do:

- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1

This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4