|
Bugzilla – Full Text Bug Listing |
| Summary: | suse-module-tools: allow to replace regenerate-initrd-posttrans | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Ludwig Nussel <lnussel> |
| Component: | Basesystem | Assignee: | Martin Wilck <martin.wilck> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aplanas, lnussel |
| Version: | Leap 15.4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ludwig Nussel
2023-07-19 08:46:00 UTC
A subpackage seems to be somewhat over-engineered to me. In the long run regenerate-initrd-posttrans should support systemd-boot. For the time being, perhaps we should simply define an override location, e.g. /etc/module-init-tools/regenerate-initrd-posttrans or /usr/local/bin/regenerate-initrd-posttrans, and execute that if present? Those locations can't be used by packages. Reserved for the admin. I wouldn't create a new subpackage either. What about just putting the script alongside the other scriptlets? > Those locations can't be used by packages. Reserved for the admin. That was intentional. As long as you're still experimenting (as I am inferring from comment 1), can't you just create a script as an admin? That said, we can check both /etc and /usr/etc, of course. Well, the stuff is entering Factory so even if locations may not be final I still try to avoid hacks that just bite later. So what about moving /usr/lib/module-init-tools/regenerate-initrd-posttrans into suse-module-tools-scriptlets? I'd rather not mix the kernel scriptlets with this. Replacing the scriptlets and replacing regenerate-initrd-posttrans are two independent things. I think creating another subpackage is the right thing to do, even if I previously said the contrary. It's consistent with the way we've handled this previously. Well, the package is called suse-module-tools-scriptlets and provides suse-kernel-rpm-scriptlets. So IMO it's perfectly set up to also host other scripts and have more provides, like eg. suse-dracut-rpm-scriptlets (In reply to Ludwig Nussel from comment #6) > Well, the package is called suse-module-tools-scriptlets and provides > suse-kernel-rpm-scriptlets. So IMO it's perfectly set up to also host other > scripts and have more provides, like eg. suse-dracut-rpm-scriptlets True, but as I said, one may very well want to replace the kernel scriptlets but not r-i-p, or vice versa. If we need to make this customizable, the customizations shouldn't be all-or-nothing. I'd argue the other way around :-) The current use case is to replace all-or-nothing anyway. So no need to make it more complex right now :-) Your argument to split off the kernel scriptlets was related to "systems with file triggers only". This one is about replacing dracut with systemd-boot. To my understanding these are two different things, even if _you_ happen to try both at the same time right now. No? Anyway, https://github.com/openSUSE/suse-module-tools/pull/77 I actually went back to the scriptlets as file triggers can't fail transactions :-( The requirements are the same though. Need to replace code that is meant to be used with grub with something compatible with sd-boot. Please have another look at the upstream PR. reviewed ok, thanks! This is an autogenerated message for OBS integration: This bug (1213459) was mentioned in https://build.opensuse.org/request/show/1109139 Factory / suse-module-tools Closing per comment 13. Closing per comment 13. |