guix-install.sh calls "update-rc.d", which doesn't exist on a Gentoo system. Instead of trying to support all possible init systems, or make assumptions regarding how the init system works, I'd suggest simply dropping support for anything other than upstart and/or systemd. Users of smaller distros using unusual/traditional init systems can add support for guix theirself. The safest and most portable option would likely be to simply point to the init script at the end of the install, and tell the user to copy that file to the proper directory and enable it, copy and modify it to fit their system, or use it as a template for whatever their init system happens to be. It's less user-friendly in the "run it and forget it" sense, but it won't break a user's already working system, or error out in new and fun ways.
Toggle quote (6 lines)> guix-install.sh calls "update-rc.d", which doesn't exist on a > Gentoo system. Instead of trying to support all possible init > systems, or make assumptions regarding how the init system > works, I'd suggest simply dropping support for anything other > than upstart and/or systemd.
I think we can safely assume that if ‘update-rc.d’ exists it will work a certain way (i.e. there aren't multiple incompatible ‘update-rc.d’s around), and that the real bug is that the script checks for a random directory in /etc instead. It should test for the script(s) it uses, not related symptoms. Kind regards, T G-R
Hello Tobias, ZC, I created a gentoo VM (i686 / following gentoo handbook) and triedthe official upstream guix installer. It worked properly, not detecting the OS init system, I think this isbecause the gentoo handbook made me install cronie instead of plaincron, so there's no "/etc/init.d/cron" file. And so it did not try toinstall the guix-daemon service init.d file through update-rc.d.And told me to run the daemon manually, which worked OK. Running it with a local guix-install.sh + binary tarball with mypending changes (which includes openrc support). It also workedproperly, detecting the OS as being openrc managed and doing whatis needed. So, I'll still cook up a patch to fix sysvinit detection, becauseassuming sysvinit on the mere presence of /etc/init.d/cron is notreally the right thing to do. (and the fix will need to be testedon a sysvinit-based distro, which I'll do) But on the other hand, I don't know what to do with this bug report,I cannot reproduce the exact problem, and I'm not trying all the otheravailable cron variants from gentoo (bcron, dcron, fcron). So either ZC tells us more about his setup and shows us more outputto be able to understand what did go wrong, or we cannot help further. Couldn't keep ZC CC'ed as the issue was created without his emailaddress, let's hope he follows it via another way... -- Vincent Legoll