Closed dnkmmr69420 closed 10 months ago
sounds good to me, if you'd like to PR it lmk, otherwise I could probably crank it out tomorrow!
ok looking further into this it looks like it might require a bit of a rethink of how the current update system works, I'm not totally sure how i'd integrate this yet but i'll definitely have a crack at it tomorrow,
sounds good to me, if you'd like to PR it lmk, otherwise I could probably crank it out tomorrow!
I would PR it if I know what to modify
sounds good to me, if you'd like to PR it lmk, otherwise I could probably crank it out tomorrow!
I would PR it if I know what to modify
you'll want to look at run_updates
and run_update_scripts
, run_updates
runs all of the required updates, run_update_scripts
runs all of the scripts in a single dir, specified as an argument
How do I add multiple dirs with /etc/ublue-update.d being the most prioritized?
closing this because of this: https://github.com/ublue-os/ublue-update/pull/102
/usr/lib/ublue-update.d
should be the least prioritized as well. It is kind of similar how udev rules and systemd unit file locations are prioritized as well.With this change, you can have a read only location for the update scripts but users can modify them by making a new file in
/etc/ublue-update.d
that has the same name as the original file in/usr/lib/ublue-update.d
Maybe there should be a way to blacklist an update script in/usr/lib/ublue-update.d
if a user desires to disable an update script entirely. So yeah it would be handled similarly as udev-rules and systemd unit files.Pull Request: https://github.com/ublue-os/ublue-update/pull/100