Remove /usr/lib/dkms/common.postinst instances/handling

[evelikov]

System information

Type	Version/Name
Distribution Name	Any
Distribution Version	Any
Kernel Version	Any
Architecture	Any
OpenZFS Version	2.2.99, 2.2.0-rc3, 2.1.12

Describe the problem you're observing

The openzfs spec file has been using /usr/lib/dkms/common.postinst since day 1 with commit f375757. Somewhat recently the spec file was updated to less parsing of dkms status with 063c83a, although the common.postinst invocation remained.

I'm not an rpm/spec expert, so it's not entirely clear what's the purpose of the posttrans hook and common.postinst. Off the top of my head, it seems like you want dkms autoinstall, although I'm not 100% sure - @behlendorf @jeremyvisser any pointers?

I'm in the process of removing common.postinst see dell/dkms#339 and this is the only user that I can see of that script. If the dkms autoinstall and other dkms commands are not sufficient please let me know - I would be happy to fix those up.

Describe how to reproduce the problem

• run a dkms package which includes Remove embedded DESTDIR in make variables, honour them dell/dkms#339
• try to build the rpm/spec -> common.postinst script is missing, packaging fails

Include any warning/errors/backtraces from the system logs

NA

[jeremyvisser]

Responding because I was tagged, although I'm not sure how much weight my opinion carries here as someone outside the project.

The %posttrans hook is important during upgrades because it happens after the old version's %preun hook is called, whereas the %post hook happens before.

It sounds like common.postinst and dkms autoinstall are functionally equivalent. In which case it would be reasonable to use it. I'm assuming we can safely depend on dkms autoinstall, since appears to have been in DKMS since basically forever.

One change of behaviour this would introduce is that dkms autoinstall would build and install all DKMS modules, not just ZFS. If a build failure occurs, even in a non-ZFS module, then it would technically happen as part of installing ZFS. Maybe this is fine, e.g. RPMs that rebuild the entire mandb or similar.

I'm a fan of simplicity, so if "dkms autoinstall" is the recommendation, then I like the sound of that; especially since it's already used by the dkms.service systemd service. Or if we care strongly about not unexpectedly building an unrelated module in the ZFS RPM scripts, then we could "dkms install -m %{module} -v %{version}" would be a reasonable compromise.

(Disclaimer: I haven't tested either option myself yet.)

[evelikov]

Thanks for the input - your observation aligns with my impression that using dkms autoinstall or dkms install -m ... should be functionally identical.

That said, I have zero experience with the OpenZFS ecosystem. If more experienced developers/users can try the suggestions and spot issues, I won't mind looking into them ;-)