On Fri, Jul 25, 2014 at 01:44:40PM -0400, Mike Pinkerton wrote: > >Mattdm then followed with 2 1/2 additional topics: > >1a. Identifying different Fedora products -- fedora-release-* > >contents and /etc/os-release > As I understand it, you are trying to decide where and how to set a > flag that will signal the "product" that is either installed or to > be installed. There was mention of dropping "product specific > snippets in /usr/lib/os-release.d/" as one solution. > > Does it have to be any more complex than the approach used by > systemd? If fedora-release were to drop all product specific > snippets in /usr/lib/os-release.d/, then a system admin could use a > symbolic link in /etc/os-release.d to flag which product (or no > product) he wanted installed. Similar to: So, one catch is that os-release.d, with snippets, isn't currently supported by the upstream standard. (If there is work to make it so, awesome.) And it's not completely trivial, because either /etc/os-release needs to be regenerated on change to the .d snippets, or else software which reads that file (like agetty) needs to be updated to follow the .d directory too. But also, ideally, the contents of /etc/os-release aren't just notes -- they actually reflect the state of the system. Having it managed by RPM (or some higher-level tool, theoretically) is helpful there. Here: > Then, if a system admin wanted to change the box to a server, or to > a non-productized box, he could simply change the symbolic link to: > /etc/os-release.d/product -> /usr/lib/os-release.d/server.product the _name_ has changed, but you don't necessarily have any of the actual software (either installed or running) that makes it "Fedora Server". That's significantly less useful. > /etc/os-release.d/product -> /usr/lib/os-release.d/generic.product > and then run whatever product syncing tool you develop -- perhaps: > dnf product-sync Okay, so, yeah -- something like that would be needed. But if we're gonna have such a tool, might as well make it also update the os-release information. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
