3 ms·

Of course it'd be better, but I don't think a simple declarative language could easily cover the breadth of what is currently done in postinstall scripts.

• pxc 5y ago
  From: > Linux distributions: Can we do without hooks and triggers? (2019) https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-triggers/ https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-tri... > If we want to get rid of hooks, we need another mechanism to achieve what we currently achieve with hooks. > If the hook is not specific to the package, it can be moved to the package manager. The desired system state should either be derived from the package contents (e.g. required system users can be discovered from systemd service files) or declaratively specified in the package build instructions—more on that in another blog post. This turns hooks (arbitrary code) into configuration, which allows the package manager to collapse and sequence the required state changes. E.g., when 5 packages are installed which each need a new system user, the package manager could update /etc/passwd just once. > If the hook is specific to the package, it should be moved into the package contents. This typically means moving the functionality into the program start (or the systemd service file if we are talking about a daemon). If (while?) upstream is not convinced, you can either wrap the program or patch it. Note that this case is relatively rare: I have worked with hundreds of packages and the only package-specific functionality I came across was automatically generating host keys before starting OpenSSH’s sshd(8).