This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------J2quNGboU2PfKBqEBBlyiAk0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 3/14/25 11:56 PM, Ionen Wolkens wrote:
I don't think so, it's more the idea in itself that I dislike than the implementation. Not that the latter helps with its kind of unintended hacked-on-top linux-mod-r1 implementation that (as you know) not all
ebuilds can use right now... but I generally want to avoid requesting improvements given it's unlikely it'd change how I feel about this.
So what I'm hearing from this is that you simply dislike sys-kernel/dkms itself, and would be okay having it treecleaned as you don't think
anyone should use it, but out of respect for the fact that someone else packaged it and cares about it are refraining from submitting a
treeclean request.
However, you are taking the opportunity of eclass review to register
your conscientious objections to the existence of the dkms software, and stating your reservations about anyone making use of it for example in
an eclass on the grounds of the aforementioned skepticism that the
software should exist / be packaged.
I can respect that opinion, but it's also going to influence my view of
this discussion, namely, that when you critique this proposal, your
critique isn't actually a critique of the proposal, but a statement that
in a distro about choice, your choice is the other choice, not this choice.
I think there's room in Gentoo for both choices, as long as the choices
are implemented well for their respective users, which I think that this
dkms proposal is.
As noted on PR, *if* we really want to support rebuilding for multiple kernels it's something that could be done with a linux-mod-r2 eclass
rather than dkms (not that it wouldn't require work because of the way current linux-info works, and some ebuilds would need to be adapted in
a multilib kinda way), and I'm not convinced the "rebuild at boot" is
really meaningful esp. with distribution kernels that are controlled
by the PM.
PM limitations could be improved in future EAPIs, like a way to have
proper hooks for modules and initramfs rebuilding so that we wouldn't
have to rely on (not really slot-able) virtual/dist-kernel and
duplicated initramfs generation. It could potentially also clean old
modules safely then. Such hooks system would also be handy for other
things like rebuilding gtk icon cache and such rather than doing it per-ebuild (we may already have a bug for this somewhere?).
"proper hooks" would work exactly like pkg_postinst in that you are able
to run gtk icon cache regeneration via a PM hook after a package is
installed. Other package managers have explored the same design space,
so we can know that it works, and also *how* it works.
The defining nature of a PM hook as opposed to a pkg_postinst command is
that it operates per installation session (a complete emerge run) as
opposed to running once per package, and that it is injected into
packages by the PM rather than requiring each package to add code to pkg_postinst.
It will not and cannot provide much of anything in the way of additional facilities above and beyond pkg_postinst in terms of targeting other
kernel targets outside of virtual/dist-kernel. It's possible to trigger
an action based on installing a /boot/vmlinuz-* or /lib/modules/*/
filesystem entry recorded in the vdb inside CONTENTS, but that helps
nearly not at all, given the extreme frequency of users using something
other than dist-kernel, such as gentoo-sources.
The gentoo-sources kernel is not even installed via portage, it is inconceivable that a future EAPI hook system could run a PM hook in
response to `make install modules_install`.
But fine, let's ignore all that. What command would you like to run in
such a PM hook?
Other distros that have such hooks, run... `dkms install`. :) Because it
has to trigger on installing a new kernel, and because the whole point
of a hook is to do things *outside* of an individual package recipe,
which means it doesn't have access to the environment file and cannot
know how to build a particular module unless there's a PM-independent
framework such as dkms to do so.
Since PM hooks give you nothing but the ability to run the same action, triggered by multiple packages, only once instead of once per package,
it logically infers that you can still upgrade linux-mod-r1 today,
without waiting for "PM hooks" to materialize. Simply... have
linux-mod-r1 execute a pkg_postinst that loops over all installed
kernels and builds for all of them.
This is strictly a subset of what "PM hooks" can do, but only because
"PM hooks" would also run whenever a kernel is installed or upgraded,
and gentoo-kernel-*.ebuild cannot recursively trigger emerge
@module-rebuild (nor could "PM hooks", but "PM hooks" could trigger
`dkms install` if module sources were installed to the dkms framework,
which you have rejected as hacky).
And I don't feel that this is all important/urgent enough that we need
to establish (hacky) dkms usage in the interim as a "better than
nothing" solution. *Vast* majority of users only care about one kernel,
at most the old just need to be able to boot into a console to fix
issues if something went wrong (that nvidia-drivers may mismatch with userspace is not great, but not getting GPU acceleration is not the
the end of the world in that situation).
Not great but, if one rare user really needs to rebuild for multiple
kernels, there are still (unintuitive) ways to do that in the interim
such as emerging modules multiple times by pointing to different
linux sources -- but again emphasis on that not really many need this.
Sorry but I do not understand at all where you are coming from. The dkms proposal is presenting itself as a possible alternative and arguing that
it's stable, reliable, robust and a permanent option with no intention
of ever being declared obsolete and being removed from ::gentoo.
It is indisputable that there are people who regard dkms as value-add in
its own right -- that is why there is a "sys-kernel/dkms" package in the
first place, you know -- and the people in that camp will not accept any
other solution as answering their needs, which I think is a compelling
proof that this isn't
"a hacky interim solution that is better than nothing"
Which is total misrepresentation of the entire discussion.
Moreover, you're arguing how dkms is "hacky interim solutions" and
refusing to consider it and instead saying that there are "still
(unintuitive) ways to do that in the interim" and then you
unenthusiastically talk about something you're plainly not at all
convinced about either.
How is it that you can tell someone who claims to be proposing a
non-hacky solution:
"""
no, you're wrong, your solution is in fact a hack actually. I don't like
it, hacks are gross and we shouldn't add hacks. Instead, I propose a
different hack which people should use instead. Maybe one day someone
will propose an unspecified PMS solution for this.
"""
No. Sorry. You're the one proposing hacky interim usage as a "better
than nothing" solution.
Building modules inside a package does have significant usefulness for
the purpose of e.g. rolling out cached binary packages to a fleet of
boxes, but I can't accept the notion that hackily changing the kernel
sources and repeatedly running `emerge @module-rebuild` is a good option
either as an interim or a permanent approach to build modules for
multiple kernels.
--
Eli Schwartz
--------------J2quNGboU2PfKBqEBBlyiAk0--
-----BEGIN PGP SIGNATURE-----
wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ9hMkwUDAAAAAAAKCRCEp9ErcA0vV6D4 AQCoopFefILG7c6cd+j5APC/wnApAVoqi7J/+ouIjQKA1AD/cnkXmClNPfezOIlCuuyT8Iy7yl2H qfuqwxZlUaAKBwk=
=UbPi
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)