Maintainer scripts vs. systemd services

[raisjn]

i think these scripts should not contain only "echo" statements, still. i'd like to re-enable them for remux, since remux only starts/stops the remux service (and not xochitl)

[Eeems]

Ideally we should also add preupgrade and postupgrade.

Also I think we should be consistant with our naming and prerm/postrm should be preremove/postremove.

[matteodelabre]

Ideally we should also add preupgrade and postupgrade.

Also I think we should be consistant with our naming and prerm/postrm should be preremove/postremove.

Opkg does not provide preupgrade and postupgrade hooks, since it follows the .deb scripts convention. This also is where the scripts naming comes from. I agree that the naming is inconsistent, but I’d argue it’s less confusing to follow the existing convention.

However, the preinst, postinst, prerm and postrm scripts all receive a status argument from which we can deduce whether the package is being installed or upgraded:

• During initial installation, the sequence of actions is:
  1. Call preinst install
  2. Unpack package files.
  3. Call postinst configure.
• During an upgrade:
  1. Call prerm upgrade.
  2. Call preinst upgrade.
  3. Unpack new package files.
  4. Call postrm upgrade.
  5. Remove old package files.
  6. Call postinst configure.
• During the removal:
  1. Call prerm remove.
  2. Remove package files.
  3. Call postrm remove.

Note that there are more possible values for the status argument that are used in rarer situations. See the flowcharts in Debian documentation. This information should be added to our documentation.

[matteodelabre]

i think these scripts should not contain only "echo" statements, still. i'd like to re-enable them for remux, since remux only starts/stops the remux service (and not xochitl)

My opinion is still that installing a package should not automatically start/enable the installed application, in general. We can think about a situation where another application which captures long presses on the middle button is already running. This would create a conflict between the two processes, which may confuse the user, and complicate testing.

I assume you’re thinking in the perspective of a fully graphical package manager where the user does not see any output from the terminal. In this case, a user who installs rmkit would be rightly confused if it does not start automatically after installing. But tying the enabling of an application to its installation means that an user wanting to temporarily stop using rmkit needs to uninstall it, instead of simply disabling it.

All in all, I’d say that it would be preferable if the graphical package manager could handle the enable/disable action by itself. It would solve both of these issues.

[Eeems]

I'd prefer to abstract those arguments away and make it dead simple by generating the scripts for a package that handles calling the correct package level install/upgrade/remove script.

My opinion is still that installing a package should not automatically start/enable the installed application, in general. We can think about a situation where another application which captures long presses on the middle button is already running. This would create a conflict between the two processes, which may confuse the user, and complicate testing.

In which case, the packages should be marked as conflicts so the end user can't do this.

All in all, I’d say that it would be preferable if the graphical package manager could handle the enable/disable action by itself. It would solve both of these issues.

Maybe also provide a script that automatically runs a different set of autosetup scripts when an environment variable is set?

[matteodelabre]

I'd prefer to abstract those arguments away and make it dead simple by generating the scripts for a package that handles calling the correct package level install/upgrade/remove script.

I think we’re having two separate discussions here, let’s move one of them to another issue.

My opinion is still that installing a package should not automatically start/enable the installed application, in general. We can think about a situation where another application which captures long presses on the middle button is already running. This would create a conflict between the two processes, which may confuse the user, and complicate testing.

In which case, the packages should be marked as conflicts so the end user can't do this.

If we follow the Debian semantics, “neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Having similar functionality or performing the same tasks as another package is not sufficient reason to declare Breaks or Conflicts with that package”. In the scenario I described above, the two packages can be installed alongside each other, it’s simply that running both at the same time creates a conflict. Much like you usually don’t want to run two fullscreen games at the same time on your computer, but it does not prevent you from installing several games.

All in all, I’d say that it would be preferable if the graphical package manager could handle the enable/disable action by itself. It would solve both of these issues.

Maybe also provide a script that automatically runs a different set of autosetup scripts when an environment variable is set?

I was thinking of something totally independent of Toltec, so that we can avoid increasing the complexity of creating packages. Maybe the graphical package manager could simply inspect whether a package installs new systemd services and ask if the user wants to enable them after installing.

[Eeems]

I think we’re having two separate discussions here, let’s move one of them to another issue.

Sure, opened #60

If we follow the Debian semantics, “neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Having similar functionality or performing the same tasks as another package is not sufficient reason to declare Breaks or Conflicts with that package”. In the scenario I described above, the two packages can be installed alongside each other, it’s simply that running both at the same time creates a conflict. Much like you usually don’t want to run two fullscreen games at the same time on your computer, but it does not prevent you from installing several games.

Fair enough. This would still be a problem with the package itself, as it should be smart enough to determine if all the conditions required to allow it to run are valid before trying to run. Now understandably we don't have proper standards around a bunch of that yet. Doing evdev grab tests is one simple way for certain things, but we don't have a good way for other things like the framebuffer. I do think the argument to allow packages to automatically start/enable on install goes away if we provide pre/post upgrade scripts in #60. As well as some mechanism for a gui to be aware of how to enable/start a package without it having to be built into the gui application itself.

I was thinking of something totally independent of Toltec, so that we can avoid increasing the complexity of creating packages. Maybe the graphical package manager could simply inspect whether a package installs new systemd services and ask if the user wants to enable them after installing.

The issue with this is that it requires the installer application to know what to do with every package, which isn't fair to it. I'd much rather have a standard at the package level that we maintain for automated setup, but not run it by default.

[matteodelabre]

@raisjn @Eeems Do you still think that this needs to be improved? If so, are there any examples of packages that may benefit from it? How?

[raisjn]

As well as some mechanism for a gui to be aware of how to enable/start a package without it having to be built into the gui application itself.

this is the underlying motivation for this issue - if someone installs a package with a systemd service and is away from their computer, how can they enable it? this is low priority atm since COVID lockdown causes most people to be near computers all the time. once cafes, offices and schools open up again, it will be more relevant

however we can resolve the issue of "graphical installer needs to be able to turn on services for packages that have them" will resolve this issue. current packages this might affect: draft, oxide remux, genie (and all services they might depend on)

[matteodelabre]

What about adding a Services: field with the list of systemd services installed by a package to the control file of that package? Once the package is installed, this list would be available under /opt/lib/opkg/info/<pkgname>.control.

[Eeems]

Hmm, perhaps. This doesn't take into account a package that contains multiple services but where only one may be enabled at a time.

[matteodelabre]

Isn’t this use case covered by the Conflicts= declarations in the respective service unit files?

[Eeems]

Right, but how would the UI application know which one to start automatically?

[matteodelabre]

Ask the user which one they want?

[Eeems]

I guess so, it does mean extra parsing though.