Upcoming /usr/etc layout on openSUSE may cause issues with bedrock.

[kurumushi]

It's already started on tubmbleweed, and will probably be coming to a future release of openSUSE Leap. openSUSE is adopting a new filesystem layout in which /etc/ contains only user modified files, and /usr/etc/ contains defaults, much in the same way that systemd keeps defaults in /lib/systemd/system, and user modified files in /etc/systemd/system.

This already caused me issues when I tried to hijack the current snapshot of opensuse tumbleweed, as files like nsswitch.conf and others that were expected to be found in /etc were not there, since they had already been moved to /usr/etc by default.

https://en.opensuse.org/openSUSE:Packaging_UsrEtc Gives some more detail on the reasoning and their suggested fixes.

I know openSUSE seems to be a low-interest distro for bedrock, so this is more of an FYI report than a request to do anything at the moment. Although It's possible other distros could adopt a similar practice in the future.

[paradigm]

I greatly appreciate the heads up here. The fact we don't have a maintainer for distros like OpenSUSE means we're dependent on people bringing stuff like this to my attention.

I think both Clear Linux and Solus do something similar. Maybe NixOS as well? I wouldn't be surprised if others follow suit. Even if no individual distro that does this has strong interest in the Bedrock community, collectively they justify attention here.

Happily I don't see any theoretical problem here. Getting these distros to play nicely with other distros should be possible, although it may be a fair bit of work and testing.

We'll probably want to build a table something like:

Filename	Bedrock interest			Distro specifics
	Global	Symlink	Config	Distro	Default dir	/etc override	Guaranteed <file>.d	Notes
profile	no	no	yes	Debian	/etc		Yes
				OpenSUSE	/usr/etc		?
sudoers	yes	no	yes	Debian	/etc		Yes	.d requires #includedir
				OpenSUSE	/usr/etc		?	?

The table should cover all /etc files Bedrock has an interest in, including:

• bedrock.conf [global] etc items
• bedrock.conf [symlinks] items that are in /etc
• bedrock.conf [etc-symlinks] items
• bedrock.conf [etc-inject] items

for each of those, we'll want to collect per-distro information for:

• All distros with a maintainer listed here
• Solus
• Clear Linux
• OpenSUSE Tumbleweed

Once we've got a good overview of what we need to be working towards, we can come up with strategies that works cleanly across all variations. Once we've implemented it, we'll need to test against various combinations. I should note here before I forget that we need to consider how a given strategy plays with hijacking for all global files.

@Titaniumtown You've shown excitement to work on Bedrock. Is building this table something you'd be interested in doing?

This already caused me issues when I tried to hijack the current snapshot of opensuse tumbleweed, as files like nsswitch.conf and others that were expected to be found in /etc were not there, since they had already been moved to /usr/etc by default.

I follow the issue for other files, like /etc/profile and /etc/sudoers, but not for specifically /etc/nsswitch.conf. If you didn't mention it, I wouldn't thought to include it in the eventual manifestation of the above proposed table.

[Titaniumtown]

@paradigm thanks for including me! I will definitely look into this!

[kurumushi]

Opensuse appears to be doing some magic with theirs so it may be a bit trickier, here are the rules followed from what I understand:

1. /usr/etc is for packager provided configurations, /etc/ is for user changed files.
2. If either file.conf or file.conf.d/ exists in /etc, then /usr/etc/file.conf* is ignored.
3. If there is a file.conf.d folder, each file is read in alphabetical order, by it's application, overriding any lines in file.conf that match.

Number 3 is the confusing one to me, because it seems like they'd need to get pretty much every single piece of software to standardize their config files to make it work properly. It could also cause problems if a program on the opensuse strata conforms to number 3, but a different strata does not. Causing them to effectively be reading different config files if .conf.d is used.

[paradigm]

What you are describing is (close to but not quite exactly) what https://en.opensuse.org/openSUSE:Packaging_UsrEtc calls "Variant 1." There are also Variants 2 and 3 to consider. As I read this, the choice is per-package, which means we'll need to figure out how OpenSUSE handles it for each package we're interested in.

I know Clear Linux and Solus both do something comparable here, but the specifics may differ, which is why we need to build a table that includes them as well.