os-release: Manage os-release outside of baselayout

[ReillyBrogan]

Summary

• Add new package os-release which manages the os-release file.

[EbonJaeger]

@HarveyDevel noted in Matrix that if this makes baselayout appear as broken when running eopkg check, users will try to reinstall baselayout, breaking their system. We might want to make sure that eopkg check knows to ignore the os-release file when this lands.

[ermo]

With this PR installed, /etc/os-release looks good, but lsb_release looks like it's missing its data...? This is how it looked after 2 reboots on my end with the packages from this PR all installed:

ermo@solus:~/repos/getsolus/monorepo [os-release* +2 ~3 -0 !]
$ cat /etc/os-release 
NAME="Solus"
VERSION="4.6"
ID="solus"
VERSION_CODENAME=convergence
VERSION_ID="4.6"
PRETTY_NAME="Solus 4.6 Convergence"
ANSI_COLOR="1;34"
HOME_URL="https://getsol.us"
SUPPORT_URL="https://help.getsol.us/docs/user/contributing/getting-involved"
BUG_REPORT_URL="https://dev.getsol.us/"
LOGO="distributor-logo-solus"
ermo@solus:~/repos/getsolus/monorepo [os-release* +2 ~3 -0 !]
$ lsb_release -a
LSB Version:	n/a
Distributor ID:	n/a
Description:	(none)
Release:	n/a
Codename:	n/a
ermo@solus:~/repos/getsolus/monorepo [os-release* +2 ~3 -0 !]
$  eopkg info -f lsb-release-data
/usr/lib/tmpfiles.d/lsb-release-data.conf, type: library, size: 64, sha1sum: d065eb300229cb416fee75167acf743700f2179e
/usr/share/os-release/lsb-release, type: data, size: 110, sha1sum: a13202479fbc38e3f55f3e41fae50b42ce9e3de1
Package found in Local repository:
Name                : lsb-release-data, version: 4.6, release: 1
Summary             : lsb-release data file
Description         : lsb-release data file
Licenses            : MIT
Component           : system.utils
Dependencies        : 
Distribution        : Solus, Dist. Release: 1
Architecture        : x86_64, Installed Size: 174.00  B, Package Size: 1.39 KB
Reverse Dependencies: lsb-release

ermo@solus:~/repos/getsolus/monorepo [os-release* +2 ~3 -0 !]
$ cat /usr/share/os-release/lsb-release
LSB_VERSION=1.4
DISTRIB_ID=Solus
DISTRIB_DESCRIPTION="Solus"
DISTRIB_RELEASE=4.6
DISTRIB_CODENAME=convergence

[ermo]

FTR, this is waiting on the feature where the /usr-merge script becomes resilient to baselayout re-installs.

blocked-by: #4118

Context: @HarveyDevel and @sheepman4267 both pointed out that users will run eopkg check and then decide to re-install baselayout to fix that, because that's what we taught them to do... 😭

[ReillyBrogan]

Theoretically if a user sees a broken eopkg check as a result of this then that implies that they have a fully updated eopkg. That means that we can ensure that baselayout is ignored by the eopkg-check (if it isn't already). I've been thinking that we need to make the usr-merge script run every boot, right now it skips it if the marker file is found, but that means that if a user does something where the system now needs to be usr-merged again (such as installing 32bit libraries after the system has already been usr-merged or somehow having eopkg do something stupid) that it won't run again. I think the logic could be modified so that it starts up, checks whether the symlinks are present and then only displays the message to the user if it has to do work.

[silkeh]

That means that we can ensure that baselayout is ignored by the eopkg-check (if it isn't already).

/etc/os-release is already ignored, probably because its a configuration file:

$ echo 'MYVALUE="bork"' | sudo tee -a /etc/os-release
$ sudo eopkg.bin check baselayout
Checking integrity of baselayout    OK
$ sudo env LC_ALL=C eopkg check baselayout
Checking integrity of baselayout    OK
$ sudo eopkg.bin sf /etc/os-release
Searching for /etc/os-release
Package baselayout has file /etc/os-release

I haven't tried it with the packages from this PR, but I don't see how that would be different.

right now it skips it if the marker file is found, but that means that if a user does something where the system now needs to be usr-merged again (such as installing 32bit libraries after the system has already been usr-merged or somehow having eopkg do something stupid) that it won't run again. I think the logic could be modified so that it starts up, checks whether the symlinks are present and then only displays the message to the user if it has to do work.

That's pretty much what I had in mind for #4118.

[silkeh]

LGTM, please rebase to fix conflicts!