pkgbase: return most config files back to ^/etc

[kevans]

Summary

A series of commits spread these out throughout the tree, rather than using .PATH reachover or some other mechanism to achieve the needed effect. This was a fairly contentious move, and many have expressed (probably mostly privately) desire for the old structure to be largely restored.

This commit restores almost all of etc/ that got moved out. libexec/rc tentatively remains untouched. Any files moved back to the etc/ top-level continue to be installed from the Makefile that currently handles installation, as it's easier to make sure they're installed in the correct package this way. Files added to subdirectories of etc/ have had their installation moved to etc/<subdir/Makefile instead, as most of these tend to be logically grouped anyways.

One exception to the old structure is that I did *not* reinstate etc/etc.<arch> just for /etc/ttys. The various ttys.<arch> files instead got moved to etc/ttys.<arch> and sbin/init reaches into etc/ for those.

Test Plan

Run make packages before and after, compare METALOGs. This is the diff:

root@viper:/usr/obj/usr/src/amd64.amd64# diff -u METALOG.old METALOG.new
--- METALOG.old 2020-02-14 15:32:45.084499000 -0600
+++ METALOG.new 2020-02-14 16:27:56.085682000 -0600
@@ -216,8 +216,6 @@
 ./etc/bluetooth type=dir uname=root gname=wheel mode=0755
 ./etc/bluetooth type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/bluetooth type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/bluetooth type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/bluetooth type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/bluetooth/hcsecd.conf type=file uname=root gname=wheel mode=0600 size=1277 tags=package=bluetooth,config
 ./etc/bluetooth/hosts type=file uname=root gname=wheel mode=0644 size=245 tags=package=bluetooth,config
 ./etc/bluetooth/protocols type=file uname=root gname=wheel mode=0444 size=1046 tags=package=bluetooth,config
@@ -235,10 +233,6 @@
 ./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/defaults type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/defaults/bluetooth.device.conf type=file uname=root gname=wheel mode=0644 size=3923 tags=package=bluetooth,config
 ./etc/defaults/devfs.rules type=file uname=root gname=wheel mode=0600 size=2397 tags=package=runtime,config
 ./etc/defaults/periodic.conf type=file uname=root gname=wheel mode=0644 size=12491 tags=package=utilities,config
@@ -340,7 +334,6 @@
 ./etc/pam.d type=dir uname=root gname=wheel mode=0755
 ./etc/pam.d type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/pam.d type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./etc/pam.d type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./etc/pam.d/atrun type=file uname=root gname=wheel mode=0644 size=257 tags=package=at,config
 ./etc/pam.d/cron type=file uname=root gname=wheel mode=0644 size=135 tags=package=utilities,config
 ./etc/pam.d/ftp type=file uname=root gname=wheel mode=0555 size=467 tags=package=utilities
@@ -910,8 +903,6 @@
 ./rescue/zstdcat type=file uname=root gname=wheel mode=0555 size=12352456 tags=package=rescue
 ./rescue/zstdmt type=file uname=root gname=wheel mode=0555 size=12352456 tags=package=rescue
 ./root type=dir uname=root gname=wheel mode=0755
-./root type=dir uname=root gname=wheel mode=0755 tags=package=utilities
-./root type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./root type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./root type=dir uname=root gname=wheel mode=0755 tags=package=utilities
 ./root/.cshrc type=file uname=root gname=wheel mode=0644 size=868 tags=package=runtime,config

[kevans]

Phab's rendering of this is absolutely unhelpful and not quite what I envisioned; review tip: the only interesting changes are in /Makefile's

[kevans]

• don't move newsyslog.conf.5 -- whoops.

[philip]

Thank you!

[rgrimes]

Why not go back exactly how it was before? Why change additional things like ttys (note that the use of arch subdir symatics is matching to other parts of the tree. How did you arrive at this patch, what was the mechanics you went through? Why not put rc.d back? What about rather than using .PATH have the reachover to call into etc/Makefile to install the sub component? I do need to look at this much closer,. Thats all for now.

[kevans]

Breaking this comment up a bit to respond to it:

In D23690#520893, @rgrimes wrote:

Why not go back exactly how it was before? Why change additional things like ttys (note that the use of arch subdir symatics is matching to other parts of the tree.

In this specific case, separate subdirs seemed silly- each subdir will have exactly one file named ttys, and there will be nothing else to install per-arch. It also more closely matches the paths as-installed on the system; I see /etc/ttys, I'm inclined to cd /usr/src/etc; vim ttys<tab> and I'll immediately realize how these things are organized rather than searching through one more layer of etc nested within the top-level etc.

How did you arrive at this patch, what was the mechanics you went through?

Manually going through the commits in ^/etc and moving the files back, then modifying Makefiles to reflect the new location.

Why not put rc.d back?

I see this as a separate issue and separate review, because there's also a vocal segment that want to explore alternatives to our rc in base. As it is, this review will already get broken up into N commits rather than just one, I'd like to have a completely separate discussion about what to do with rc.

What about rather than using .PATH have the reachover to call into etc/Makefile to install the sub component?

If we were to move the installation to etc/Makefile, I would not include any reachover. I do not like the idea of adding N targets back to etc/Makefile that manage this in some action-driven way, rather than the current "describe the files with CONFS" data-driven kind of installation. Installation in ^/etc would just move the CONFS from these Makefiles into that one, and adding *PACKAGE for each conf group. There's been some comments that it's easier to keep the packaging correct this way, as you only need to change the PACKAGE in one spot in the common case rather than also going over to ^/etc and changing the config file's package, too. I'm relatively indifferent.

[rgrimes]

In D23690#520894, @kevans wrote:

Breaking this comment up a bit to respond to it:

Perhaps we should have this discussion on arch? I find phabricator a horrible place to try and do this level of a discussion.

[kevans]

In D23690#520897, @rgrimes wrote:

In D23690#520894, @kevans wrote:

Breaking this comment up a bit to respond to it:

Perhaps we should have this discussion on arch? I find phabricator a horrible place to try and do this level of a discussion.

Sure- please do raise it on arch, and we can continue there.

[jilles]

The bin/sh part looks OK.

Perhaps the periodic scripts can stay where they are since they are code, not configuration.

[bdrewery]

sbin/devfs/Makefile

4–5

How come build handling for devfs.rules moved but not devfs.conf? It seems weird to justify this simply because 1 is in a subdir and 1 is not.

[cem]

Please, and asap.

[kevans]

sbin/devfs/Makefile

4–5

This is a concern that was raised on the mailing list, as well; does it make more sense to push devfs.conf out (and, indeed, the rest that I didn't move installation of to ^/etc/Makefile) as well, or pull devfs.rules (and the rest that went to subdirs of ^/etc) back?

The argument for pulling it back would seem to be to allow one-off make distribution here in sbin/devfs, but it's kinda more annoying to track down where the install happens if it comes back.

[cy]

Sooner the better.