What do package managers do? Install packages, obviously! But that is not everything. In my opinion, package managers do enough to be characterized as general automation frameworks. For example:

  • manage configurations and configuration files
  • manage custom compilation options and flags
  • provide isolation or containerization
  • make sure a specific file is present in a specific place given specific conditions
  • change installation files or configuration based on architecture or other conditions

Not all package managers do all of the above, but you get the idea.

Nix even manages your entire setup with a single configuration file.

It occurred to me that package management could theoretically be managed by an automation framework.

What do I mean by automation framework? Ansible, chef, puppet, or Sparrow.

Now imagine if you were to use one of those package managers as an automation framework. For most of them, it would suck. (nix is a notable exception). So maybe common package managers are just bad automation frameworks?

What if we used an automation framework as a package manager? Well currently, it might also suck, but only because it lacks the package definitions. Maybe it is not a bad experiment to have a distribution managed by a modern automation framework like Sparrow.

What are the benefits?

  • usable on other distributions
  • more easily create your own packages on the fly
  • Greater customization and configurability
  • use a known programming language that is easy to read to define packages and other functions, instead of a DSL
  • your package manager can easily automate just about any task using the same syntax and framework
  • MajorHavoc@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    I’m now switching over to a model where I only use ansible to manage installation and configuration tying machines together and where I use debian packaging for, well, packaging.

    Makes sense. I imagine the push model of Ansible had a lot to do with the speed issues? I can imagine how a solid .deb would be much more performant.

    Sure, the old ways are bad in many ways but they often get the work done.

    As someone who unapologetically uses Makefiles with even the newest and shiniest tech, I couldn’t agree more with this sentiment!

    • callcc@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Makes sense. I imagine the push model of Ansible had a lot to do with the speed issues? I can imagine how a solid .deb would be much more performant.

      It’s part of the problem, but the other part is that you have to re-do the package building all the time. Alternatively you fiddle with tags and only run part of your roles (which is a hassle anyways because ansible does not really have good abstractions that help encapsulation).