Expand the multi-user installer to support Linuxes with systemd #2026
Conversation
- darwin installer: delete hardware report, not necessary - moves os-specific code from the darwin installer to to `poly_*` functions - adds profile.d support to the profile targets, which automatically handles many distros which don't have a /etc/bashrc but do have an /etc/profile.d - /bin/bash -> /usr/bin/env bash - document why each excluded shellcheck check is excluded - rename the multi-user to Daemon-based
|
The diff is a bit tedious to read, but essentially the install-multi-user script is calls |
|
Reviewed by downloading install-multi-user and diffing with a local copy of install-darwin-multi-user |
|
@shlevy would you mind posting that diff? |
|
Can we do something about the extreme verbosity of the installer? Why is it necessary to tell the user about every sudo command separately? What useful information do messages like 'in order to give $1 a safe home directory' convey? ("Rule of Silence: When a program has nothing surprising to say, it should say nothing.") In fact, why don't we just re-exec most of the installer under sudo, rather than invoke sudo a gazillion times? |
|
I've heard from a number of people that they really like the verbosity, because they feel like they can look back and know exactly what happened, should they want to undo it. I've even been contracted to make other installers for other tools be similarly chatty... I have also heard the opposite, of course. Maybe there is a happy medium? Maybe we could cut down the # of lines per sudo? or a |
…ons Nix Grep would ignore files that didn't exist, but would complain about files in a directory if the directory didn't exist. Simply check for the directory first, prior to grepping it.
We use grep instead of an equality check because it is difficult to extract _just_ the user's note, instead it is prefixed with some plist junk. This was causing the user note to always be set, even if there was no reason for it.
|
After some non-blocking cleanup patches, it is confirmed working on
|
|
This is ready to go as far as my testing reveals, and I've opened #2027 to backport it to the maintenance branch. |
|
To me doing this much stuff in a curl-piped-to-bash style script sounds scary when it comes to uninstallation, upgrads and such. E.g. currently the uninstall process is a dead simple I wonder if anybody has looked into https://github.com/jordansissel/fpm for building multi-user installer packages for Deb/RPM/Pacman? |
Backport #2026: Expand the multi-user installer to support Linuxes with systemd
Good call: this does make it very unclear how to uninstall! I don't think the answer is an equally magic "uninstaller" (there be dragons) so exploring how to leverage package manager on each system would be very valuable. (the package manager solutions might help provide an upgrade path as well?) ".... who would uninstall Nix?!" 😁 Continuing such thoughts.... "We've upgraded you to NixOS as well, you're welcome" 😉 |
|
Yeah I'm aware of that. I don't think it's an optimal approach though, so I've created a competing implementation: https://github.com/dezgeg/nix-fpm-multiuser |
|
@dezgeg I think it would make sense to also provide pre-build packages. Otherwise there is a bootstrap issue to build packages without having nix. The nix support in Travis + uploading release artifacts to github should allow to automate this. |
poly_*functions
handles many distros which don't have a /etc/bashrc but do have an
/etc/profile.d
Tested on: