Comment by heinrichhartman | Hacker News Reader

Comment by heinrichhartman | Hacker News Reader

heinrichhartman

I don't get why we would want to allow packages to run any scripts before/after the installation. I get why it's necessary at this point, but the true solution should get away without executing any code.

IMHO, a package should deliver a set of files to certain directories. That's it.

It should not overwrite existing files, that were installed by other packages. It should not change existing files in any way.

It might advise the system to trigger certain reindexing actions (systemd daemon reolad, update man-db, etc.) but doing this should be the duty of the package manager, not the package itself.

AFAIK, nix and Solaris' pkg are pretty close to this ideal.

A big advantage that this has, on top of security, is that:

- packages can be uninstalled safely and without side-effects

- package contents can be inspected (pkg contents)

- corrupted installations can be detected using checksums (pkg fix)

- package updates/installs can be rolled back using file system snapshots.

Because the scope of 'certain reindexing actions' is potentially unbounded. Suppose you have a large piece of software that uses plugins, which it finds by reading a 'plugins.xml' file. Now, when you install a plugin from the package manager, you need to modify 'plugins.xml' in some arbitrary fashion. You simply cannot constrain the entire software world to operate in a file-oriented, declarative manner.

> You simply cannot constrain the entire software world to operate in a file-oriented, declarative manner.

You can, if the community wants to go in that direction.

Ideally the software which loads "plugins.xml" is updated to support a conf.d-like directory full of "plugin-pkg1.xml" through "plugin-pkgN.xml", each owned by separate packages. Many OSS projects have done this.

If that's not possible (closed-source, too much work, whatever) then it seems simple enough to build a separate XML-merging tool that the package manager invokes which combines the separate XML files during package installation.

And JSON-merging and YAML-merging and TOML-merging and .bashrc merging and .properties merging and ...

... and hopefully programmers realise that building all those things and shipping them is harder than just supporting a directory with the plugins in it. Or maybe even just punt with a wrapper that does it at startup.

Honestly: the defence of shit software and user-hostile developers never ceases to amaze me.

You're just saying, "I can constrain whatever I want!".

Which is fine and all, but don't expect users to flock to your distribution that doesn't support $SOFTWARE because you decided they do things wrong.

Running arbitrary code may be needed if you want to upgrade an existing installation in-place. Imagine that you are upgrading to a new major version and want to migrate the existing configuration to a new format.

This need not be an automatic action, though; you might choose to postpone the migration, and offer a separate tool for the user to run.

This prevents any packages from depending on such a package, though: they can no longer be automatically installed, because their dependency cannot, too.

This changes the concept of package management seriously enough.

Easy, implement the config upgrade in the software (launcher) itself. 1. check config version on launch. 2. if old version upgrade.

Yes, ideally, every version of software that changes any external data format (e.g. of config files) should always accept both new and old versions.

But, unfortunately, some software does not, and it still needs to be packaged.

True. And the only effective solutions I can think of are extremely ressource intensive (man hours) and therefore unrealistic. (Lile wrapping non-compliant apps and using mandatory access control for enforcement)

And then you have moved stuff around and solved absolutely nothing, but you have created a new, permanent surface for security issues.

Well, for me this is a question who owns the config file:

* If the package owns the file, and the user is not supposed to make changes to it, then package updates may do whatever to the file on update. It's good practice though, to leave a copy of the old file in /lost+found.

* If the user is allowed to make modification, then the user owns it. The configuration syntax becomes and API and should be treated as such. Breaking changes should be rare, preceded by a deprecation period and announced as major versions. As you say, it's questionable if such updates can/should be automated.

What about binary formats like gpg keyrings?

I like to see the dpkg/apt system enhance to add audit feature - able log all the files added/modified/deleted as part the installation process, ideally in html format.

Any admin can view the contents to debug or spot any potential security issues.

Forget admins, I'd love to have that as a user. I want to know where the application is and where it stores its data. And I mean all of the places.

> I don't get why we would want to allow packages to run any scripts before/after the installation.

That’s because you probably never built a package management system. If you limit the package management system to the actions you propose it’s only usable for iOS type apps and that could be useful but then you still need a solution for managing the rest of the system.

Please have a look at nix and solaris first. Both are making a compelling case against your answer

Solaris is dead. I looked at Nix and it has postInstall actions which can run arbitrary commands and scripts, so it doesn’t fit the description.

You might have misunderstood "postInstall" -- rather understandably so since elsewhere (debian packages, ...) for precisely the issue discussed in the article: arbitrary scripts executed after package installation.

In Nix postInstall (and preInstall, as well as preBuild/postBuild, etc) specifying commands to execute before/after the corresponding "phase" -- so if a package is "almost" good to go with just "make install", you could use postInstall to do something like copy a file omitted by upstream's installation target.

The point is that postInstall in Nix is part of how the package itself is constructed-- in contrast to commands run after installing the package. There is no equivalent for this in Nix in a fundamental way (not by policy or for technical reasons).

How would you solve a task like creating an user group or things that are more complicated then dropping some files on the disk?

Adding new systemd service, for example just requires me to put a file into `/etc/systemd/system`. Many other applications work like this as well: Apache configs, /etc/sudoers.d on Debian, more examples in `/etc/?.d`

It's generally a good practice to make your system open for extension but closed to modifications [1].

There is no reason, the user database can not work the same way. Just have the system scan `/etc/passwd.d/*` on boot/reload and drop files there.

[1] https://drive.google.com/file/d/0BwhCYaYDn8EgODUxZTJhOWEtMTZ...

User management could be handled as part of the package metadata, rather than an install script.

Schema migrations would still need a script or something though.

Then you need to add support for this features to the package manager, I imagine that the package manager will never cover all uses so you would need for rare cases the ability to run a script.

That script could be sandboxed to only have access to its packages' files.

Your suggestion only seems to work if the software in the package is stateless. In the case of a DBMS the approach would just put data upgrade problems in another place and in some cases make them harder to solve as well.

State is a different problem. Usually programs don't mutate their executables.

Mutable, persistent state is usually put under /var and is user-owned. Package updates should not touch data in there.

Reply on news.ycombinator.com