5 ms·

It is required by Debian Policy §6.2 (https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#maintainer-scripts-idempotency https://www.debian.org/d

• zinekeller 5y ago
  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.
• gorgoiler 5y ago
  And the install process may hang / crash / lose power etc. There are lots of reasons for one to rerun a post install that aren’t an upgrade.
• mschuster91 5y ago
  > A maintainer could, theoretically, figure out whether its an upgrade or not by checking to see if a version is being passed into it. Or use good old lock files in the software's data directory to determine what the current state is (e.g. /var/lib/mysql/debian-10.3.flag) and which updates need to be run. Lock files aren't rocket science.