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
OpenPGP_signature.asc
Description: OpenPGP digital signature
