fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

Stephen Gallagher sgallagh at redhat.com
Mon Jun 30 20:43:50 UTC 2014

Hash: SHA1

On 06/30/2014 04:22 PM, Lennart Poettering wrote:
> On Mon, 30.06.14 16:16, Stephen Gallagher (sgallagh at redhat.com)
> wrote:
>> On 06/30/2014 04:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher
>>> wrote:
>>>> Any chance that systemd wants to build a hostnamectl-like 
>>>> interface for setting the os-release values? That would make
>>>> life a lot easier on us, as we could reconfigure that file
>>>> if-and-when a fedora-release-$PRODUCT package was installed
>>>> in a %post snippet.
>>> What would be the advantage over including /usr/lib/os-release
>>> in the package directly? What kinds of fields could be modified
>>> in this way?
>> Well, ideally we'd like the majority of the file to be owned by 
>> fedora-release and then just add the one or two additional
>> fields specific to the products programmatically.
>> I suppose though that we could just carry complete duplicates in
>> each fedora-release-* package. Particularly if we end up adding
>> a fedora-release-nonproduct (or however we name it) package to
>> solve the depsolving issues as suggested by James Antill.
> I really don't understand why /usr/lib/os-release should have an
> API to modify. It describes the vendor operating system image,
> really, and his hence strictly not dynamic. We should never invent
> mechanisms that make files in /usr subject to runtime
> configuration. That would be completely backwards.

Well, it's semi-dynamic. I suppose I'm treating it more like an
additive drop directory.

In a sense, there's a certain amount of this definition that every
Fedora install will have. The Products then add to this definition. A
basic piece of it is mandatory, but the outer edges are add-ons.

Since we can't change the standard that requires os-release to allow
drop directory extension, that leaves either replacing the file
completely (which is how we're likely to actually do it) or adding an
API to allow extending it for limited cases such as evolving into one
of the Products from a non-product starting point.

Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the devel mailing list