Mailing List Archive: 2024-02-26-debianutils-drops-installkernel-dep: add news item

2024-02-26-debianutils-drops-installkernel-dep: add news item

Feb 26, 2024, 9:13 AM

Post #1 of 11 (160 views)

This draft news item accompanies:
https://github.com/gentoo/gentoo/pull/35533

Random packages requiring some tool from Debian should not cause the
kernel installation process to change.

The dropping of the debianutils dependency in ca-certificates has
already caused some surprises due to installkernel being depcleaned. The
origin of the problem lies here in debianutils, users unknowingly use
and rely on installkernel but do not have it in their world file because
it was implicitly pulled in by some package that happens to use the
run-parts command.

And also the other way around. If I am one of the users that wants to do
everything manually, I should not have my 'make install' unknowingly
altered by some package that I installed which pulled debianutils into
the depgraph.

Drop this unused runtime dependency (which is against policy to begin
with) and its accompanying flag.
This will be accompanied with the following news item:

Title: installkernel is no longer implicitly installed
Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
Posted: 2024-02-26
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/installkernel
Display-If-Installed: >=sys-apps/debianutils-5.14-r1
Display-If-Installed: app-misc/ca-certificates

/sbin/installkernel is a script called by the kernels 'make install' as well
as by the distribution kernels post install phase. If you are reading this
then chances are you use and rely on installkernel and what follows is
essential for you.

Previously sys-kernel/installkernel was implicitly installed on many systems
via a dependency in sys-apps/debianutils. This dependency was toggled
by the "installkernel" USE flag, and enabled by default.

sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
an essential package installed on many systems. However, this
dependency was recently removed. As a result many users may find that
sys-apps/debianutils and therefore sys-kernel/installkernel are no longer
part of the dependency graph and will therefore be cleaned up by
'emerge --depclean'.

Removing sys-kernel/installkernel from your system WILL change the
way kernels are installed by 'make install'! Instead of the versioned
/boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
copy bzImage (or equivalent for you arch) into /boot. This image
may not be picked up by your bootloader or its configuration tools.

To avoid surprises from such implicit dependencies from happening
again in the future, the dependency on sys-kernel/installkernel in
sys-apps/debianutils is removed. And as such sys-kernel/installkernel
is only installed on the system if it is either explicitly selected or
pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)).

User Action Required (all users)
====================

Users who currently have sys-kernel/installkernel installed, must
ensure that it is explicitly selected by explicitly emerging it:

emerge --noreplace sys-kernel/installkernel

Users who find that sys-kernel/installkernel has already been
cleaned from their systems and are therefore effected by
the change in kernel installation described above should
re-install sys-kernel/installkernel and then re-install their
kernel.

emerge sys-kernel/installkernel
cd /usr/src/linux (or other location of the kernel sources)
make install

Note that this re-installation is not required for users of the
distribution kernels (e.g. gentoo-kernel(-bin)).

See also: https://wiki.gentoo.org/wiki/Installkernel

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

watermanpaint at posteo

Feb 26, 2024, 2:39 PM

Post #2 of 11 (158 views)

Permalink

On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote:
> Previously sys-kernel/installkernel was implicitly installed on many systems
> via a dependency in sys-apps/debianutils. This dependency was toggled
> by the "installkernel" USE flag, and enabled by default.
>
> sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
> an essential package installed on many systems. However, this
> dependency was recently removed.
In my opinion, the last sentence reads as if app-misc/ca-certificates was
recently removed. I suggest rewording the passage as follows:

Until recently, sys-apps/debianutils was in turn pulled in by
app-misc/ca-certificates, an essential package installed on many systems.
This is no longer the case.
> As a result many users may find that ...

Best,
--
Lucio Sauer

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

xxc3ncoredxx at gmail

Feb 26, 2024, 6:28 PM

Post #3 of 11 (155 views)

Permalink

On Mon, Feb 26, 2024 at 22:39:13 +0000, Lucio Sauer wrote:
> On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote:
> > Previously sys-kernel/installkernel was implicitly installed on many systems
> > via a dependency in sys-apps/debianutils. This dependency was toggled
> > by the "installkernel" USE flag, and enabled by default.
> >
> > sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
> > an essential package installed on many systems. However, this
> > dependency was recently removed.
>
> In my opinion, the last sentence reads as if app-misc/ca-certificates was
> recently removed. I suggest rewording the passage as follows:
>
> Until recently, sys-apps/debianutils was in turn pulled in by
> app-misc/ca-certificates, an essential package installed on many systems.
> This is no longer the case.
>
> > As a result many users may find that ...
>

Agreed. I was confused for a second reading it since it was the first
I'd heard of ca-certificates being removed before I realized that was
not the case at all.

- Oskari

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

1i5t5.duncan at cox

Feb 26, 2024, 7:55 PM

Post #4 of 11 (155 views)

Permalink

Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
excerpted:

> Removing sys-kernel/installkernel from your system WILL change the way
> kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image may not
> be picked up by your bootloader or its configuration tools.

I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".

That isn't the case here -- I've been getting versioned images without the
debianutils-based installkernel script for years.

I long ago (when installkernel was still part of debianutils according to
comments in my version, presumably the debianutils default-enabled USE was
set when it was split out to avoid just this sort of surprise at that
time) created my own version based on the debianutils version, but
bashified/comment-and-var-name-clarified and with a config file that
determines various behavior (along with behavior for my other kernel-
related build/patch/config/etc scripts).

Maybe "will likely", or "will, unless you've specifically configured other
behavior", or "will, unless you've previously setup your own solution"?
("Will" can then be SHOUTED or not, as desired, because the statement is
then sufficiently conditional regardless.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Re: Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

eschwartz93 at gmail

Feb 26, 2024, 8:21 PM

Post #5 of 11 (153 views)

Permalink

On 2/26/24 10:55 PM, Duncan wrote:
> Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
> excerpted:
>
>> Removing sys-kernel/installkernel from your system WILL change the way
>> kernels are installed by 'make install'! Instead of the versioned
>> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
>> copy bzImage (or equivalent for you arch) into /boot. This image may not
>> be picked up by your bootloader or its configuration tools.
>
> I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".
>
> That isn't the case here -- I've been getting versioned images without the
> debianutils-based installkernel script for years.
>
> I long ago (when installkernel was still part of debianutils according to
> comments in my version, presumably the debianutils default-enabled USE was
> set when it was split out to avoid just this sort of surprise at that
> time) created my own version based on the debianutils version, but
> bashified/comment-and-var-name-clarified and with a config file that
> determines various behavior (along with behavior for my other kernel-
> related build/patch/config/etc scripts).

Gentoo comes with several different installkernel options, and the
critical thing here is that you need to *have* a program called
`installkernel`.

Via the package manager provided functionality, that means the
"installkernel" package. There has been a lot of flux over the last few
months. It used to be "installkernel" or "installkernel-systemd", or
even "installkernel-gentoo".

Surely, anyone can package an alternative installkernel in their
overlay. Do we need a virtual/installkernel for this? Is that the only
way to set the desired tone in the news item?

I'm okay with news items having an implicit "the contents of this news
item apply unless you have reimplemented the stated packages in ways
that gentoo doesn't officially package and without using an overlay".

Or even more simply, all news items have an implicit "unless you know
better, including that you know *why* you know better".

Someone could be writing that `installkernel` script for use with a
kernel package that has an actual RDEPEND on sys-kernel/installkernel,
too. Nothing changes.

--
Eli Schwartz

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

andrewammerlaan at gentoo

Feb 26, 2024, 8:23 PM

Post #6 of 11 (153 views)

Permalink

On 27/02/2024 03:28, Oskari Pirhonen wrote:
> On Mon, Feb 26, 2024 at 22:39:13 +0000, Lucio Sauer wrote:
>> On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote:
>>> Previously sys-kernel/installkernel was implicitly installed on many systems
>>> via a dependency in sys-apps/debianutils. This dependency was toggled
>>> by the "installkernel" USE flag, and enabled by default.
>>>
>>> sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
>>> an essential package installed on many systems. However, this
>>> dependency was recently removed.
>>
>> In my opinion, the last sentence reads as if app-misc/ca-certificates was
>> recently removed. I suggest rewording the passage as follows:
>>
>> Until recently, sys-apps/debianutils was in turn pulled in by
>> app-misc/ca-certificates, an essential package installed on many systems.
>> This is no longer the case.
>>
>>> As a result many users may find that ...
>>
>
> Agreed. I was confused for a second reading it since it was the first
> I'd heard of ca-certificates being removed before I realized that was
> not the case at all.
>
> - Oskari

Yes I see how this wording can be confusing. Fixed locally and in the
GitHub PR, Thanks.

Best regards,
Andrew

Re: Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

andrewammerlaan at gentoo

Feb 26, 2024, 8:58 PM

Post #7 of 11 (153 views)

Permalink

On 27/02/2024 04:55, Duncan wrote:
> Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as
> excerpted:
>
>> Removing sys-kernel/installkernel from your system WILL change the way
>> kernels are installed by 'make install'! Instead of the versioned
>> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
>> copy bzImage (or equivalent for you arch) into /boot. This image may not
>> be picked up by your bootloader or its configuration tools.
>
> I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL".
>
> That isn't the case here -- I've been getting versioned images without the
> debianutils-based installkernel script for years.

I'm going to disagree here, this *is* the case. If you have it installed
and remove it, then the way the kernel is installed will change.

The point is that I have seen *many* users on our various support
channels that thought they either:
- did not use installkernel before when they actually did and therefore
disregard the instructions in the news item, or
- thought the news item did not apply to them because they misunderstand
what 'make install' does, and therefore disregard essential instructions
in the news item, or
- complain that they don't want automation, when they have in fact been
using this tool for ages. Then remove installkernel.

Such misunderstandings can, and have, lead to systems breaking. I do not
want this to happen again and therefore I want it to be very clear that
if you remove installkernel that this will change things for you.

> I long ago (when installkernel was still part of debianutils according to
> comments in my version, presumably the debianutils default-enabled USE was
> set when it was split out to avoid just this sort of surprise at that
> time) created my own version based on the debianutils version, but
> bashified/comment-and-var-name-clarified and with a config file that
> determines various behavior (along with behavior for my other kernel-
> related build/patch/config/etc scripts).

Yes sure, you can make your own /sbin/installkernel. And that means you
don't have sys-kernel/installkernel installed and therefore none of this
applies to you.

But for users that do have it installed now, and have it depcleaned,
behavior is changed always. It is therefore not a case of "will likely"
because it will always.

As a side note, latest version of installkernel also supports reading a
config (install.conf), not sure if this suits your needs but might be
worth to check out.

> Maybe "will likely", or "will, unless you've specifically configured other
> behavior", or "will, unless you've previously setup your own solution"?
> ("Will" can then be SHOUTED or not, as desired, because the statement is
> then sufficiently conditional regardless.)

If you have setup your own solution, then you a) don't have this package
installed to begin with, and b) clearly know what you are doing. This
news item is for those users that a) do currently have installkernel
installed and b) often don't know the intricacies of what 'make install'
and installkernel do.

Best regards,
Andrew

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item [ In reply to ]

ulm at gentoo

Feb 26, 2024, 10:26 PM

Post #8 of 11 (150 views)

Permalink

>>>>> On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote:

> Title: installkernel is no longer implicitly installed
> Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
> Posted: 2024-02-26
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-kernel/installkernel
> Display-If-Installed: >=sys-apps/debianutils-5.14-r1
> Display-If-Installed: app-misc/ca-certificates

I have only some small remarks about spelling and style:

> /sbin/installkernel is a script called by the kernels 'make install' as well

s/kernels/kernel's/ (also occurs more times below)

> as by the distribution kernels post install phase. If you are reading this
> then chances are you use and rely on installkernel and what follows is
> essential for you.

> Previously sys-kernel/installkernel was implicitly installed on many systems
> via a dependency in sys-apps/debianutils. This dependency was toggled
> by the "installkernel" USE flag, and enabled by default.

Use either double quotes (which I'd prefer) or single quotes throughout.

> sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
> an essential package installed on many systems. However, this
> dependency was recently removed. As a result many users may find that
> sys-apps/debianutils and therefore sys-kernel/installkernel are no longer
> part of the dependency graph and will therefore be cleaned up by
> 'emerge --depclean'.

> Removing sys-kernel/installkernel from your system WILL change the
> way kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image

s/you/your/

> may not be picked up by your bootloader or its configuration tools.

> To avoid surprises from such implicit dependencies from happening
> again in the future, the dependency on sys-kernel/installkernel in
> sys-apps/debianutils is removed. And as such sys-kernel/installkernel

Comma after "such"?

> is only installed on the system if it is either explicitly selected or
> pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)).

> User Action Required (all users)
> ====================

> Users who currently have sys-kernel/installkernel installed, must
> ensure that it is explicitly selected by explicitly emerging it:

Avoid the double "explicitly".

> emerge --noreplace sys-kernel/installkernel

Put a # sign in front to make clear that it's a command? Alternatively,
indent the line (applies also for the three commands below).

> Users who find that sys-kernel/installkernel has already been
> cleaned from their systems and are therefore effected by
> the change in kernel installation described above should
> re-install sys-kernel/installkernel and then re-install their
> kernel.

Above you wrap lines at 75 chars, but here it's down to 60.

Please make it consistent. GLEP 42 suggests "The text body should be
wrapped at 72 characters."

> emerge sys-kernel/installkernel
> cd /usr/src/linux (or other location of the kernel sources)

bash: syntax error near unexpected token `('

But seriously, some users will copy and paste these commands, so making
it a bash comment starting with # may be better.

> make install

> Note that this re-installation is not required for users of the
> distribution kernels (e.g. gentoo-kernel(-bin)).

> See also: https://wiki.gentoo.org/wiki/Installkernel

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item v2 [ In reply to ]

andrewammerlaan at gentoo

Feb 26, 2024, 10:44 PM

Post #9 of 11 (150 views)

Permalink

On 27/02/2024 07:26, Ulrich Mueller wrote:
>>>>>> On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote:
>
>> Title: installkernel is no longer implicitly installed
>> Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
>> Posted: 2024-02-26
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: sys-kernel/installkernel
>> Display-If-Installed: >=sys-apps/debianutils-5.14-r1
>> Display-If-Installed: app-misc/ca-certificates
>
> I have only some small remarks about spelling and style:

Thanks for your comments. Here's version 2:

Title: installkernel is no longer implicitly installed
Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
Posted: 2024-02-26
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/installkernel
Display-If-Installed: >=sys-apps/debianutils-5.14-r1
Display-If-Installed: app-misc/ca-certificates

/sbin/installkernel is a script called by the kernel's "make install"
as well as by the distribution kernel's post-install phase. If you are
reading this then chances are you use and rely on installkernel[1] and
what follows is essential for you.

Previously sys-kernel/installkernel was implicitly installed on many
systems via a dependency in sys-apps/debianutils. This dependency was
toggled by the "installkernel" USE flag, and enabled by default.

Until recently, sys-apps/debianutils was in turn pulled in by
app-misc/ca-certificates, an essential package installed on many
systems. This is no longer the case.[2]. As a result many users may find
that sys-apps/debianutils and therefore sys-kernel/installkernel are no
longer part of the dependency graph and will therefore be cleaned up by
"emerge --depclean".

Removing sys-kernel/installkernel from your system WILL change the way
kernels are installed by "make install"! Instead of the versioned
/boot/vmlinuz-x.y.z that you are used to, "make install" will simply
copy bzImage (or equivalent for your arch) into /boot. This image may
not be picked up by your bootloader or its configuration tools.

To avoid surprises from such implicit dependencies from happening again
in the future, the dependency on sys-kernel/installkernel in
sys-apps/debianutils is removed. And as such, sys-kernel/installkernel
is only installed on the system if it is either explicitly selected or
pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)).

User Action Required (all users)
====================

Users who currently have sys-kernel/installkernel installed, must
ensure that it is explicitly selected by emerging it:

emerge --noreplace sys-kernel/installkernel

Users who find that sys-kernel/installkernel has already been cleaned
from their systems and are therefore effected by the change in kernel
installation described above should re-install sys-kernel/installkernel
and then re-install their kernel.

emerge sys-kernel/installkernel
cd /usr/src/linux # (or other location of the kernel sources)
make install

Note that this re-installation is not required for users of the
distribution kernels (e.g. gentoo-kernel(-bin)).

[1] https://wiki.gentoo.org/wiki/Installkernel
[2]
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e6ccafd58bc7401fa371d2f255d72ddae0131e6

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item v2 [ In reply to ]

hlein at korelogic

Feb 27, 2024, 9:24 AM

Post #10 of 11 (140 views)

Permalink

On 2024-02-27, andrewammerlaan wrote:

> Until recently, sys-apps/debianutils was in turn pulled in by
> app-misc/ca-certificates, an essential package installed on many
> systems. This is no longer the case.[2]. As a result many users may find
> that sys-apps/debianutils and therefore sys-kernel/installkernel are no
> longer part of the dependency graph and will therefore be cleaned up by
> "emerge --depclean".

Sorry for speaking up late: I (mis)read the second sentence differently
from others in this thread, apparently.

"This is no longer the case." might apply to the first part of the
previous sentence, "was in turn pulled in by".

Or it might apply to the second part, "an essential package installed on
many systems."

I think what's meant is the former, it is no longer pulled in. But
someone reading this cold could be forgiven for reading that as
"ca-certificates is no longer an essential package".

Unfortunately my recommendation would be to restore the mention of a
dependency, in some form or fashion, which seems to be something that
was removed due to earlier feedback in this thread.

Maybe:

Until recently, sys-apps/debianutils was in turn pulled in by
app-misc/ca-certificates, an essential package installed on many
systems. That package no longer depends on sys-apps/debianutils. As a
result many users may find that sys-apps/debianutils and therefore
sys-kernel/installkernel are no longer part of the dependency graph and
will therefore be cleaned up by "emerge --depclean".

Thanks,

Hank

Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item v2 [ In reply to ]

andrewammerlaan at gentoo

Feb 28, 2024, 4:34 AM

Post #11 of 11 (133 views)

Permalink

On 27/02/2024 18:24, Hank Leininger wrote:
> On 2024-02-27, andrewammerlaan wrote:
>
>> Until recently, sys-apps/debianutils was in turn pulled in by
>> app-misc/ca-certificates, an essential package installed on many
>> systems. This is no longer the case.[2]. As a result many users may find
>> that sys-apps/debianutils and therefore sys-kernel/installkernel are no
>> longer part of the dependency graph and will therefore be cleaned up by
>> "emerge --depclean".
>
> Sorry for speaking up late: I (mis)read the second sentence differently
> from others in this thread, apparently.
>
> "This is no longer the case." might apply to the first part of the
> previous sentence, "was in turn pulled in by".
>
> Or it might apply to the second part, "an essential package installed on
> many systems."
>
> I think what's meant is the former, it is no longer pulled in. But
> someone reading this cold could be forgiven for reading that as
> "ca-certificates is no longer an essential package".
>
> Unfortunately my recommendation would be to restore the mention of a
> dependency, in some form or fashion, which seems to be something that
> was removed due to earlier feedback in this thread.
>
> Maybe:
>
> Until recently, sys-apps/debianutils was in turn pulled in by
> app-misc/ca-certificates, an essential package installed on many
> systems. That package no longer depends on sys-apps/debianutils. As a
> result many users may find that sys-apps/debianutils and therefore
> sys-kernel/installkernel are no longer part of the dependency graph and
> will therefore be cleaned up by "emerge --depclean".

I rewrote this paragraph like this:

Until recently, sys-apps/debianutils was in turn pulled in by
app-misc/ca-certificates, an essential package installed on many
systems. However, this dependency of app-misc/ca-certificates on
sys-apps/debianutils was removed[2]. As a result many users may find
that sys-apps/debianutils and therefore sys-kernel/installkernel are no
longer part of the dependency graph and will therefore be cleaned up by
"emerge --depclean".

I think this way it should be very clear what has changed to cause the
problem.

Best regards,
Andrew

Mailing List Archive

Attached Files:

Attached Files:

Attached Files:

Attached Files:

Attached Files: