4 ms·

I still think a package manager should never execute any code at all. It should extract a package and remove its files at some point again, but that's it.

jstimpfle 10y ago
Then you need to put that maintenance code elsewhere (and invent independent mechanisms to call it). What's the benefit?
- megous 10y ago
  That's where Arch Linux (pacman) is heading slowly. The code is better tested that way, and not written multiple times by many programmers/packagers of various skill. Also, it's the difference between systemd and sysvinit - descriptive configuration vs scripting.
  - mkhpalm 10y ago
    How is that different than GitSrc or Quilt source formats in Debian?
    - megous 10y ago
      Why should it be?
barrkel 10y ago
That would require a reorientation of the whole distribution around the requirement that packages integrate only at the level of whole files. Everything from interacting services to user and password management, from drivers to application plugins, all of it would need to be integrated solely using atomic files on disk. Anything that couldn't be packaged that way would need to be rewritten or forked. You're essentially asking for a whole new operating system.
- wang_li 10y ago
  Not really. It simply means that mechanisms need to be built that enable settings changes in a OS supplied fashion. Solaris has come a long way in this with SMF's configuration utilities svccfg and svcprop. From a configuration management perspective this approach is dramatically better than scripts that try to edit text files.
- kemitche 10y ago
  This is exactly what pkg command on Solaris 11 does, though. The package manifests only are allowed to declare certain things: files, users, device drivers, and so forth. They are allowed to include service definitions as well, but services then don't need to touch anything outside of their designated area. On removal, no arbitrary code gets to run - pkg just removed the declared files, drivers, users and services. Transitioning some packages took work and thought, but overall the system seemed pretty darn good to me.
- JoshTriplett 10y ago
  Systems have already moved in that direction for years, in the form of configuration directories (ending in .d) that packages can drop configuration files into.
- alkonaut 10y ago
  Doesn't Nix offer at least an attempt at this?
  - Filligree 10y ago
    Nix offers a very good attempt at this. There are some exceptions at the NixOS level, but they're kept to a minimum; mutable state is largely kept to just restarting/starting/stopping systemd services when the system changes. And /etc is not among the exceptions; it's built as a package, just like nearly everything else. If something goes catastrophically wrong, you can still roll your system back to a previous version. (Through GRUB, if it's completely broken.) For a concrete example, /etc/passwd is generated by a single NixOS module -- that is, Nix code. That module reads a list of users provided by other modules, and makes sure to e.g. avoid any duplicates. It's impossible to switch the system into a state where two users have the same UID, so while rolling back from that would be doable, you can't get there in the first place and (nonexistent) purge code could not be run.
4ad 10y ago
Correct. This is how Solaris IPS works.
jlebrech 10y ago
https://gobolinux.org/faq.html https://gobolinux.org/faq.html
deathanatos 10y ago
It isn't that a package manager should execute code, it's that it for tasks such as "install" and "remove", that's the package manager's job, and it shouldn't execute code for that. You still need to build the package somehow, which pretty much entails executing code. For example, Gentoo's portage is quite capable of running code, since most packages are built from source, but that's done in a separate staging area; my understanding is that the completion of this process is a set of files that the package's build code wants to install. The package manager then installs them, from which it then also learns what to remove (what files belong to that package), and if anything would conflict.

jstimpfle 10y ago

Then you need to put that maintenance code elsewhere (and invent independent mechanisms to call it). What's the benefit?

megous 10y ago
That's where Arch Linux (pacman) is heading slowly. The code is better tested that way, and not written multiple times by many programmers/packagers of various skill. Also, it's the difference between systemd and sysvinit - descriptive configuration vs scripting.
- mkhpalm 10y ago
  How is that different than GitSrc or Quilt source formats in Debian?
  - megous 10y ago
    Why should it be?

barrkel 10y ago

That would require a reorientation of the whole distribution around the requirement that packages integrate only at the level of whole files. Everything from interacting services to user and password management, from drivers to application plugins, all of it would need to be integrated solely using atomic files on disk. Anything that couldn't be packaged that way would need to be rewritten or forked. You're essentially asking for a whole new operating system.

wang_li 10y ago
Not really. It simply means that mechanisms need to be built that enable settings changes in a OS supplied fashion. Solaris has come a long way in this with SMF's configuration utilities svccfg and svcprop. From a configuration management perspective this approach is dramatically better than scripts that try to edit text files.
kemitche 10y ago
This is exactly what pkg command on Solaris 11 does, though. The package manifests only are allowed to declare certain things: files, users, device drivers, and so forth. They are allowed to include service definitions as well, but services then don't need to touch anything outside of their designated area. On removal, no arbitrary code gets to run - pkg just removed the declared files, drivers, users and services. Transitioning some packages took work and thought, but overall the system seemed pretty darn good to me.
JoshTriplett 10y ago
Systems have already moved in that direction for years, in the form of configuration directories (ending in .d) that packages can drop configuration files into.
alkonaut 10y ago
Doesn't Nix offer at least an attempt at this?
- Filligree 10y ago
  Nix offers a very good attempt at this. There are some exceptions at the NixOS level, but they're kept to a minimum; mutable state is largely kept to just restarting/starting/stopping systemd services when the system changes. And /etc is not among the exceptions; it's built as a package, just like nearly everything else. If something goes catastrophically wrong, you can still roll your system back to a previous version. (Through GRUB, if it's completely broken.) For a concrete example, /etc/passwd is generated by a single NixOS module -- that is, Nix code. That module reads a list of users provided by other modules, and makes sure to e.g. avoid any duplicates. It's impossible to switch the system into a state where two users have the same UID, so while rolling back from that would be doable, you can't get there in the first place and (nonexistent) purge code could not be run.

4ad 10y ago

Correct. This is how Solaris IPS works.

jlebrech 10y ago

https://gobolinux.org/faq.html https://gobolinux.org/faq.html

deathanatos 10y ago

It isn't that a package manager should execute code, it's that it for tasks such as "install" and "remove", that's the package manager's job, and it shouldn't execute code for that. You still need to build the package somehow, which pretty much entails executing code. For example, Gentoo's portage is quite capable of running code, since most packages are built from source, but that's done in a separate staging area; my understanding is that the completion of this process is a set of files that the package's build code wants to install. The package manager then installs them, from which it then also learns what to remove (what files belong to that package), and if anything would conflict.