/etc/os-release is another file introduced by systemd to make getting system release information easier. I can put that file into systemd ebuild but maybe putting it in baselayout would make it useful for more users (scripts). Difference from lsb_release: doesn't require running shell script to get the information portably, the /etc/os-release file is guaranteed to be simple shell-like file which can be either sourced or parsed easily. Jorge suggested we should also think about providing a version number. He suggested using baselayout version like in /etc/gentoo-release -- which would as well make the file more suitable for baselayout ebuild. An example file would look like: NAME="Gentoo Linux" # maybe without Linux? VERSION=2.1 # or "Base System release 2.1"? ID=gentoo VERSION_ID=2.1 PRETTY_NAME="Gentoo Base System release 2.1" ANSI_COLOR=1;32 Shortly: - NAME and VERSION are supposed to be full, human-readable, - ID and VERSION_ID short, simple, machine-parseable, - PRETTY_NAME as it suggests, - ANSI_COLOR specifies the color to use when printing the above.
not sure about this. if we did merge it, i think we'd want gentoo-release to either not exist or symlink it in. it would help if Fedora wasn't the only one adopting this ...
I'm still not understanding the point or the improvement over /etc/lsb-release. People keep mentioning to me that it doesn't require a shell to parse, but every distro I've checked the layout is.. DISTRIB_ID=Ubuntu DISTRIB_RELEASE=11.04 DISTRIB_CODENAME=natty DISTRIB_DESCRIPTION="Ubuntu 11.04" That being said, I really don't think we could scrap /etc/lsb-release, we MIGHT be able to scrap /etc/gentoo-release but we'd need to move the necessary info into /etc/lsb-release as well since when the DISTRIB_DESCRIPTION field is missing it will read the /etc/${DISTRIB_ID-release file. And lastly, to not divert the discussion, what are you doing about the /etc/machine-id file that systemd needs?
I've asked the systemd guys to support using /etc/lsb-release but I've been met with absurdity.
baselayout doesn't install lsb-release. i don't know what does under Gentoo. as for talking to systemd upstream, i don't expect any reasonable response from them ever. i don't see how os-release is any simpler than lsb-release, but i can't get the spec to check as LF is still down in many ways.
(In reply to comment #4) > baselayout doesn't install lsb-release. i don't know what does under Gentoo. sys-apps/lsb-release
(In reply to comment #2) > I'm still not understanding the point or the improvement over /etc/lsb-release. > People keep mentioning to me that it doesn't require a shell to parse, but > every distro I've checked the layout is.. The 'lsb_release' script contains distro-specific hacks, and by the spec you're supposed to use it rather than /etc/lsb-release directly. > And lastly, to not divert the discussion, what are you doing about the > /etc/machine-id file that systemd needs? D-Bus is using that location as well, so its ebuild just moves machine-id there.
For details on the two files, see: http://0pointer.de/public/systemd-man/os-release.html http://linux.die.net/man/1/lsb_release While the lsb_release application does do some lifting, you'll see that the man page defines very similar fields to os-release.
(In reply to comment #6) > (In reply to comment #2) > > I'm still not understanding the point or the improvement over /etc/lsb-release. > > People keep mentioning to me that it doesn't require a shell to parse, but > > every distro I've checked the layout is.. > > The 'lsb_release' script contains distro-specific hacks, and by the spec you're > supposed to use it rather than /etc/lsb-release directly. > The script contains distro specific hacks only to deal with distros that don't ship /etc/lsb-release and to handle their funkiness. Look at it, its trying to work out the differences between /etc/redhat-release and /etc/debian_release into something consistent. We're shipping /etc/lsb-release, however we're not fully populating it which I would argue we should. To properly populate it we also may want to consider moving it to baselayout. DISTRIB_ID=Gentoo DISTRIB_RELEASE=2.1 DISTRIB_DESCRIPTION="Gentoo Base System release 2.1"
Well, I think we should ship one of two files. If we decide to ship lsb-release only, someone should convince systemd upstream to support the file as well. Very unlikely to succeed. But I'll probably create a small fsnotify-activated unit which will update os-release on lsb-release changes. If we decide to ship os-release only, we could make lsb_release script support that file as well. That would still fit the spec, and I think that its upstream will be more friendly to us.
at this point, i'm indifferent. /etc/gentoo-release has largely been a useless marker, so picking a different useless marker doesn't matter to me too much. vid=$(date +%Y.%m) cat <<-EOF > "${D}"/etc/os-release NAME=Gentoo VERSION="${vid} Larry" ID=gentoo VERSION_ID=${vid} PRETTY_NAME="Gentoo" ANSI_COLOR=1;32 EOF
Just my USD0.02: We should probably not include any version information in /etc/os-release at all (as Lennart suggests for rolling-release distros), so the resulting file might look like: NAME=Gentoo ID=gentoo PRETTY_NAME=Gentoo ANSI_COLOR=1;32 (Color of the bikeshed is up for debate as usual)
We should make it Gentoo Linux (or Gentoo FreeBSD etc) probably.
*** Bug 405547 has been marked as a duplicate of this bug. ***
Here is a post about the /etc/os-release file addressing some questions asked in this bug too: http://0pointer.de/blog/projects/os-release.html
added Diego's suggestion for Gentoo/<OS>, and by dropping version info as suggested by Jonathan, there's no need to generate in the ebuild itself http://sources.gentoo.org/baselayout?rev=3203&view=rev
