Add reenable hooks

[LinusCDE]

Hi,

this PR is kinda building upon PR #7 .

Since the already packaged launchers add themselves a systemd services, they need an opportunity to get reenabled when the reMarkable gets an update.

This PR just runs all the scripts found in a specific folder when doing the reenable to give packages the opportunity should they have added a script there.

[raisjn]

very nice. this is really important to having a consistent experience across upgrades

[Evidlo]

This could use more discussion. Is the purpose explicitly for reenabling systemd units after an upgrade, or something more general?

If we're just interested in systemd units, we can potentially symlink /opt/etc/systemd/system into one of systemd's search paths which is unused on the reMarkable, like /etc/systemd/system.control.

This way, toltec package authors can just store their services in /opt/etc/systemd/system and not worry about writing a post-upgrade hook.

[LinusCDE]

This could use more discussion. Is the purpose explicitly for reenabling systemd units after an upgrade, or something more general?

If we're just interested in systemd units, we can potentially symlink /opt/etc/systemd/system into one of systemd's search paths which is unused on the reMarkable, like /etc/systemd/system.control.

This way, toltec package authors can just store their services in /opt/etc/systemd/system and not worry about writing a post-upgrade hook.

That's the current main usecase for that. I didn't know we could do that alternative path. That would be a huge help as well. Though we may way we could e.g. reenable a services if needed or do other tasks that may come up in the future.

@raisjnn @Eeems do any of you have ideas that could be non-systemd related? Otherwise I also don't really see a point aside from more flexibility for package maintainers.

[Eeems]

Symlinking of systemd units doesn't seem to work properly on reboot when I've tried it in the past. Probably due to timing on when things are mounted. For that reason we have been storing our systemd files in /lib/systemd/system (the correct location for packages to store their unit files). If we can in fact handle symlinks, this would need to be done to a location under /lib/systemd/.

As for things other than systemd units, I'm not aware of any right now.

[Evidlo]

@Eeems I did some tests yesterday and it seems like you're right about symlinking units on another partition.

How about we split this into /opt/etc/entware_hooks and /opt/etc/entware_services? Packages which provide services can simply install them in entware_services, and if they want more complex behavior they can use a hook. Then the install and reenable scripts will copy/execute as needed.

[Eeems]

I like it

[Eeems]

@LinusCDE any chance you can work on this soon?

[LinusCDE]

@LinusCDE any chance you can work on this soon?

I haven't had time to look into the services. But, I think @raisjn had tested whether we could link the services directory, but there were some implications on doing this.

Seeing that many packages have some unique behaviour on whether their services should be enabled, this feature might end up unused (smaller packages might use it, but I haven't seen any likely ones).

[Eeems]

@LinusCDE any chance you can work on this soon?

I haven't had time to look into the services. But, I think @raisjn had tested whether we could link the services directory, but there were some implications on doing this.

Linking services from another partition will not work on reboot.

Seeing that many packages have some unique behaviour on whether their services should be enabled, this feature might end up unused (smaller packages might use it, but I haven't seen any likely ones).

It would still be good to have hooks for re-enabling services that were enabled before (i.e. oxide) that change the user experience. That way an upgrade doesn't have to be painful for users who aren't as tech literate. At the very least it would provide a standard we could use for upgrading the re-enable script without having to actually modify it.

[LinusCDE]

It would still be good to have hooks for re-enabling services that were enabled before (i.e. oxide) that change the user experience. That way an upgrade doesn't have to be painful for users who aren't as tech literate. At the very least it would provide a standard we could use for upgrading the re-enable script without having to actually modify it.

Good idea. Though we will need to consider all services there as still enabled by the user. A user who installs a software and then disables a service and only manually starts it, would get it re-activated after an upgrade since we can not detect well what services were enabled before. We could try to read out the old partition, but then we would need to figure out, if a user actually just made a upgrade. There could be other reasons for reenabling and reading out the old partition could have some side effects on activating services.

In short:

• Good idea
• Would enable autostart even if user may have not wanted/enabled it
• We could try to detect what was autostart, but it would be complicated to get right

[Evidlo]

It would still be good to have hooks for re-enabling services that were enabled before (i.e. oxide)

That's going to require some sort of pre-upgrade script, either run automatically on a regular basis (perhaps with a standard backup service), or manually by the user.

[Eeems]

For toltec it can be managed by the packages themselves. For this repo it would make more sense to just require the user to manage it.

[Evidlo]

Alternatively we might do as LinusCDE suggested and read the previous services and symlinks out of the old partition. We'd have to keep track of which services were created by entware, though.

Is the list of files created by opkg for each package available somewhere on disk? Maybe that could be parsed.

[Eeems]

opkg list-installed | awk '{print $1}' | xargs opkg files | grep -v 'is installed on root and has' | grep -v /opt/ | grep -v /home/root/ gives you the list of all installed files not in /opt or /home/root.

We use a variation of this to reinstall any package that has a file outside of /opt and /home/root: https://github.com/toltec-dev/toltec/blob/testing/package/toltec-bootstrap/entware-reenable#L37-L46