[gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Andrew Nowa Ammerlaan]

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: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Lucio Sauer]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Oskari Pirhonen]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Andrew Nowa Ammerlaan]

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

[gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Duncan]

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: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Eli Schwartz]

[-- Attachment #1.1.1: Type: text/plain, Size: 2304 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 18399 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Andrew Nowa Ammerlaan]

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: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item v2

[Andrew Nowa Ammerlaan]

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: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item v2

[Hank Leininger]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item v2

[Andrew Nowa Ammerlaan]

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