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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQGTBAABCgB9FiEElFlueg0TS/aEyc5qVWii3aYMopcFAmXdEw1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk0 NTk2RTdBMEQxMzRCRjY4NEM5Q0U2QTU1NjhBMkREQTYwQ0EyOTcACgkQVWii3aYM opfPNAgAqIqCLpqf8q7lS8yH8gNKx9gPOctP5eduPQHYIHRwCA3ECB/FkLJ8pPPO W8+QVxcRqX5KEgEltdM7ocDc33u9m4jv9BzJyUqftH+8q1g0rnB/BPgoXjAaDzXE m5AQ8lrV0IMM4PgoAf1U27z54lqaMGToVRW06lankPiKwfn+FnZ6Rj7Anz3gP7x9 JPdpZ8rKdHyhAKqqquzG8e4Odl8zMxjOeki8e7femynJIeAUVISOGCX6gwyZD886 /5svTaU8dMsYGFC4DQwIfy/HmYtfY+IHj9BIS/JuiO/z/h+b1m2TxopGVvBPwyKH NMpJUnhn5EIYktDIDmB9fd7ivL4+DQ==
=jZX4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmXdgJYPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uQawH/RNC+zdGcTgCU8PR1aHi2esLhoQKPjCoiPs2 TbXTNot6GayqfGIdhJTFTIARiZtUCPRGlJwFzv+7E4l48ZCe+zWERzaBpEbx/31u HVczDPDktyqXUl2U444m9i1a7OLDlPhLRPFiYwkjWAZYmWJwoSV38kUTWfNSAEQm WRBhTyZTgXjdWPRNfvdRO3naoSvxBsaibdMIThAP/dMKgIxGKlk5DHHyIOcPzmFb HWd20HH5KOEtUbdrribf4CQ/oHalPIWrNMlJ0CGBfhQIMlcPng5/XuE9OboGuBls 9rZR7dEkTGETTZ9ju2Ins3zpFwyQReBre2GPes5rP8fxuB9J+LY=
=Yq8T
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEhCjtFFJoxycMSPRUhG8GN1/rFhIFAmXeGsEACgkQhG8GN1/r FhIykBAAuPXFNpNwm2erLnXY6FeRfhd1/E9cAIzjhQHeV4wPF2vWhRmxdJwNj3i/ QXNDXdWNxzWxR4aJCi6FI5OUuWXLwMYUH1iMk6zpwrB0vLeXfe2NxIz6+7uaN7KB H/UTHkZB5o+gTrMDAnJ1XhMSuiInKR+o5bmijJFKlAVyWGSlXKkkHLQnMLY7Z5rZ gPEXYJsWHdE78IlX31pajj4ZgJc+ohS39I3GR+9XLfHakkAz5elI51EluZo9rc92 cWvIn7wFF7AIu1E5JV7CA94gU3yUuebpSh/jvHUeTL0apA/+S2pST0LODtW4OALs u3FwBLvSmywlMxzzb5elH12jNSZss/E6onf6xVsiVRuOYIl2YBAOL/RkMnmvs2lq 3pp3vAkTlMrwW5QDRvMevrEUswG2CdvVJMfHcaU9pzv07jnzXOda+QR93po3ID/h Ncw2/13/bVZc0QLpgCnOaGoAcyX8cen4e9EB0xxSceSPaoVn7hk146NddaiJirsC bLpLmozwN5DrAOiaU9Lr292/MoINv3dnxphkTyQyvAwMxxEwOXDmyBTVvUPKAjsd F0BTJ2OW26V2CCdFFxQMSif1b78DR/HXAqd9mrBNJXmdUVBaX1ySmgWYbwGxJ0k9 +6VLBP6o74iNZU/BgG9ycuLHiKMt7anaC1bixZ/nnTznSnmZ91U=
=sOm8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)