6 ms·

1) that's actually reasonable and I believe that all Debian-maintained packages follows this, but unfortunately some third-party, usually proprietary, packages

1) that's actually reasonable and I believe that all Debian-maintained packages follows this, but unfortunately some third-party, usually proprietary, packages don't follow this. 2) Huh, so it's actually there, just isn't explicit, probably because of their requirement of idempotency.

rlpb 5y ago
It is explicit: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-configuration https://www.debian.org/doc/debian-policy/ch-maintainerscript... There's also a handy summary in the same policy document: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called https://www.debian.org/doc/debian-policy/ch-maintainerscript...
asveikau 5y ago
I'm imagining it's also possible that there could be bugs in a postinstall script that make it behave differently during an upgrade. This is actually somewhat an argument that postinstall scripts are maybe a bad idea. They're quite hard to test. It's better to have the package manager simply manipulate files in a declarative fashion than have it run package-provided code that may be buggy and introduce issues.
- bestouff 5y ago
  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).
- throwaway984393 5y ago
  What you're asking for is Configuration Management, which is even worse than buggy postinstall scripts.

rlpb 5y ago

It is explicit: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-configuration https://www.debian.org/doc/debian-policy/ch-maintainerscript... There's also a handy summary in the same policy document: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called https://www.debian.org/doc/debian-policy/ch-maintainerscript...

asveikau 5y ago

I'm imagining it's also possible that there could be bugs in a postinstall script that make it behave differently during an upgrade. This is actually somewhat an argument that postinstall scripts are maybe a bad idea. They're quite hard to test. It's better to have the package manager simply manipulate files in a declarative fashion than have it run package-provided code that may be buggy and introduce issues.

bestouff 5y ago
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).
throwaway984393 5y ago
What you're asking for is Configuration Management, which is even worse than buggy postinstall scripts.