Doing a deep dive into some aspects of what garuda-specific packages are and do, especially those in the higher priority repository, garuda itself, I started noticing some concerning issues I wanted to point out.
Specifically in garuda-hooks, there is:
/usr/share/libalpm/hooks/20-os-release.hook
/usr/share/libalpm/scripts/garuda-hooks-runner
The hook, on Install and Upgrade alters /etc/nsswitch.conf in very blunt force manners any time filesystem package gets installed or updated, clobbering anything a user may have already setup, such as things like systemd-homed potentially.
This, in my perspective thoughts, should only ever be a one-time thing, and likely very much during post-installation routines, after all the base is installed, since this hook is in fact, doing more than adjusting os-release itself. Another factor in this is that /etc/os-release itself is not even owned by any package at all, as determined by pacman -Qo /etc/os-release, which is normal. But the hook was clearly designed for os-release specifically, which is fine, but why touch nsswitch.conf in a clobbering manner?
Ahh, I didn't even check if os-release itself was a symlink or not, but good to know. That one, though, I can totally agree, that part of the hook is absolutely fine. My focus was more on the concern for the additional nsswitch.conf clobbering portion, which after looking at the garuda-migrations may in fact be a viable solution, however, at the same time, would it? This is usually something you only want to touch one time for system initialization, and leave it alone, let .pacsave handle informing people of changes appropriately.
The nsswitch.conf change was implemented because of network and boot delays it was causing a long ways back before you joined the Garuda team @TNE. Perhaps the bug that necessitated the change has been rectified by now.
Huh... I'd be curious to know what was specifically causing the delays. There's a slight bit of ordering here on what to try first, but a big part is enabling of the mdns_minimal, which is specific.
Course.... Another way to partly solve this problem is come with systemd-resolved setup and configured right out of the box, remove the hooks to clobber nsswitch.conf entirely. Maybe have some install script setup the nsswitch.conf the one way the one time it should be to best work with it, perhaps in common-settings, and allow pacsave/pacnew to do it's work as intended....
Hmm.. Just checked samda-support, and yes, the same clobbering is done there as well. This is basically a sledge hammer trying to solve an edge case issue, when all it's really needing to do (in samba-support's case anyway), is add 'wins' to the end of the 'hosts' line for resolution that might be resulted from WINS lookups. Quite a lot less likely these days though that truly really is, but still it can be done.
The way that Fedora does nsswitch.conf is very specific, and there's logical reasoning behind it, first-off, they use systemd-resolved so the use of 'resolve' in this line is specific TO using systemd-resolved:
hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
This says, use files first, myhostname, mDNS, or continue if not found, then try systemd-resolved and if it's unavailable then continue but all other cases, stop, then finally nss-dns.
samba-support could effectively add wins, but that "resolve [!UNAVAIL=return] would never get to it if it's at the very end, if using systemd-resolved (which wouldn't actually be a bad thing either?)
That actually in a sense kind of depends. If using avahi-daemon, yes it does add a difference. If using systemd-resolved however, with mdns turned on within it, that can actually effectively do the same thing on its own. But either way, this can and likely should be done during the installer, and left alone afterwards, except maybe, just maybe, adding wins to the last part using a properly constructed sed line to append to the end of a line, rather than replace the line entirely as is being done currently. The initial setup could write it out as need-be initially but afterwards should be refrained from manually touching it. Especially in a manner that does not make a .pacnew or .pacsave
Okay! I can work out these changes and put in the MR's pretty soon then. iso-profiles for the initial overlay, removal from the samba-support, and removal from the garuda-hooks.
Maybe add a note too, regarding possibly adding wins to the nsswitch.conf?
There's a way to do that if I recall, even if it's not the most obvious way, it's still able to print something "You may need to add this if you intend to use it, etc.. after a package is installed?
And the beauty of it all, it won't effect any existing users, just no clobbering them in the long term.
Annnd.. Yeah. Further looking into it. WINS, has been sunset by Microsoft themselves since Windows 2000 and up. So my final draft markup for nsswitch.conf doesn't include wins, as it's obsolete.
Yep. Or in the case of Garuda Linux, it was using mdns_minimal which covers both ipv4 and ipv6 together. That's what I'm implementing it as in my current clones and soon to follow, merge-requests.
