[PATCH] /etc/os-release

  • Done
  • quality assurance status badge
Details
7 participants
  • Angelos Kapsimanis
  • bill-auger
  • Efraim Flashner
  • Ludovic Courtès
  • Maxim Cournoyer
  • ng0
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Efraim Flashner
Severity
normal

Debbugs page

E
E
Efraim Flashner wrote on 21 Jan 2019 02:17
(address . guix-patches@gnu.org)
20190121101740.GB11658@macbook41
Currently GuixSD ships without an '/etc/os-release' file. This simple
service aims to correct this.

--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 57918a48ee7c649470ab20cb7337bc5528df515e Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@flashner.co.il>
Date: Mon, 21 Jan 2019 12:16:31 +0200
Subject: [PATCH] services: Add os-release-file.

* gnu/services/base.scm (%os-release-file): New variable.
(%base-services): Add it.
---
gnu/services/base.scm | 14 ++++++++++++++
1 file changed, 14 insertions(+)

Toggle diff (34 lines)
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index d2baea0dd..7af3142cf 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -2294,6 +2294,17 @@ to handle."
(requirement requirement)
(name-servers name-servers)))))
+(define %os-release-file
+ (plain-file "os-release"
+ (string-append
+ "NAME=\"GNU Guix\"\n"
+ "PRETTY_NAME=\"GNU Guix\"\n"
+ "VERSION=\""((@ (guix packages) package-version) guix)"\"\n"
+ "ID=guix\n"
+ "HOME_URL=\"https://www.gnu.org/software/guix/\"\n"
+ "SUPPORT_URL=\"https://www.gnu.org/software/guix/help/\"\n"
+ "BUG_REPORT_URL=\"mailto:bug-guix@gnu.org\"\n")))
+
(define %base-services
;; Convenience variable holding the basic services.
@@ -2340,6 +2351,9 @@ to handle."
(udev-configuration
(rules (list lvm2 fuse alsa-utils crda))))
+ (service special-files-service-type
+ `(("/etc/os-release" ,%os-release-file)))
+
(service special-files-service-type
`(("/bin/sh" ,(file-append (canonical-package bash)
"/bin/sh"))))))
--
2.20.1
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAlxFnEQACgkQQarn3Mo9
g1EnjRAAkvxCLPzBnzylsjg6tmQbVKx/lYuDsk4CRQUAztBlT+viWsPxpmoeY6vz
9Y4nYQrDV5OrkoHg4OOv5Z8A/zFf2jjUZnDCFhut6UBmVzTIJgBdfA0o24m5CXZx
1arLiJmd8ZHYZFAP1y67nkDp/mn/dfP4AKd49eacuVTX9MBdrDL8hV1706WVsKHN
ISl77IKIrLtTWF0QiqTEmFI0B/yyf/V1600dH9vM6rNYlt1ZGUrMrmEVhJ5grpke
k2XJEuxsYVQJjXH831L1UxV0iV/C1yNUEHe0f2bhDdERVKNmjg9Tu4U9qS0KajNR
Pr8vJzgYjuUy9unDaDmqh8u0+qjxm8Dy5khfiHb/6JrrAyW4r/6yaAkocje3DgNL
SGgZXTk7SWHLywMVSeHkDOwvE9jSX06lhWoYaU2xs3Vp0k4UakUPt9rNwXW0Zajd
IbOoq7j62USxHXtGB06vyLBsyHvHCSZ6NmfltnkujzE7znDImolxqX0y5kChFUhP
/FrGmGj0A2o3Z0kBiiyaryzlgmuTY3219+ZFRhi052+8MEFbbhJqNS/jvMx7HBFp
reURJhiTPPDK+GqiXufshUT2Dr+yGNM7xvwKQbPbU8VF9qE0Bb/xWwgGkz7ow1Pd
fqYfHSpbh0Knhuz9/Y+K6C1t9dTod/2X2yTPeZwhCHC2C6lKl8o=
=jKVI
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 22 Jan 2019 13:38
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 34154@debbugs.gnu.org)
87y37cjruq.fsf@gnu.org
Hello!

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (3 lines)
> Currently GuixSD ships without an '/etc/os-release' file. This simple
> service aims to correct this.

I’m not very enthusiastic. :-)

I think /etc/os-release is a hack and the primary motivation behind it
was (I believe) to allow proprietary programs to make assumptions on the
file system layout, available services, etc. based on the distribution
running.

WDYT? Did you encounter situations where lack of this file was causing
problems?

Thanks,
Ludo’.
E
E
Efraim Flashner wrote on 22 Jan 2019 23:20
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34154@debbugs.gnu.org)
20190123072017.GA6135@macbook41
On Tue, Jan 22, 2019 at 10:38:05PM +0100, Ludovic Courtès wrote:
Toggle quote (18 lines)
> Hello!
>
> Efraim Flashner <efraim@flashner.co.il> skribis:
>
> > Currently GuixSD ships without an '/etc/os-release' file. This simple
> > service aims to correct this.
>
> I’m not very enthusiastic. :-)
>
> I think /etc/os-release is a hack and the primary motivation behind it
> was (I believe) to allow proprietary programs to make assumptions on the
> file system layout, available services, etc. based on the distribution
> running.
>
> WDYT? Did you encounter situations where lack of this file was causing
> problems?
>

I found a man page online from freedesktop.org¹, it seems that it's been
aborbed by systemd at some point. It looks like some build systems can
try to get information from it during building if they have
distro-specific things to do. The only software that I know of that we
have that would use it would be inxi.
guix environment --ad-hoc inxi-minimal -- inxi -S
"Distro: Unknown" isn't that big of a deal, and we could just submit a
patch upstream if we really wanted it fixed.

That said, I'm happy enough to plop it in my own os-config and drop the
patch.


--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAlxIFa4ACgkQQarn3Mo9
g1HSCxAAu/xa49dXm2NaSMIpRcnjHL7w3LF0SVVJFVYUpasa9wmiOiqdFAMZ93pg
mpMAdSkaEc6LON4ksjNeFSKwcLd8lkRrtu1Kj5D/+kIA5j5XLK4b0JQdk27WMnte
croqcDBBn6g1zjfcrCdVdxjKkKvVz/uDgK/iaXQ+ASYojOtmHDjsgDETaVn9plLs
ytHR6T6KsqXqsbgI7ifVjrSGngWwHoJR9b91Pjpf/Lw3EBiT1NaQUwLB6fnU5TJ7
OBXTbH+5/goGgxd1vESNb/qPF1FP48GuQgzxYM1hOhW3Lhnd2auNE0N/IbvTQCdg
6alM/WNVFvUTpjzYs5GlfGAjxlTb2RrW5nZfyQ3Vvfvq0x7WIxJgXpsA8PhSwjaB
C49cuR0rwdamcW6AjardQ+jvfgXdAkfD3Hec08N5oHNeyCFZZJDSghZenZ/uo8g1
rkJkUU9IZgyyMfG9PLyw+Nc6cE7PrEITkvpg1PYU9gsW7znMShSEH+mmJrXgafKz
6gKEPDCSLRWVK2kZz0hiRixt+wxyrTgkm+SWIwb4Ns6NyrtT+LajLhdhkOEVJFjz
Q4S1fFRSxF+2+9IdVteqmzzQzRsQSARz8rrrLW8WQPTxTty2dyq0z/vE8vEbOc9q
X7VPlbamOMs/arKRR5cEe92vcEbpA/Op5crR/7WV5Y/DbI6XoWw=
=a83l
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 23 Jan 2019 01:59
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 34154@debbugs.gnu.org)
87h8dzheyp.fsf@gnu.org
Hello,

Efraim Flashner <efraim@flashner.co.il> skribis:

Toggle quote (3 lines)
> I found a man page online from freedesktop.org¹, it seems that it's been
> aborbed by systemd at some point.

OK.

Toggle quote (3 lines)
> It looks like some build systems can try to get information from it
> during building if they have distro-specific things to do.

That is precisely the kind of bad practice that I’d rather not
encourage. :-)

Toggle quote (5 lines)
> The only software that I know of that we have that would use it would
> be inxi. guix environment --ad-hoc inxi-minimal -- inxi -S "Distro:
> Unknown" isn't that big of a deal, and we could just submit a patch
> upstream if we really wanted it fixed.

It has other problems:

Toggle snippet (11 lines)
$ guix environment -C --ad-hoc inxi-minimal -- inxi -S
sh: tty: command not found
Can't exec "ps": No such file or directory at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 17535.
Use of uninitialized value in split at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 17535.
Can't exec "ps": No such file or directory at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 3052.
Use of uninitialized value in split at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 3052.
Can't exec "ps": No such file or directory at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 17535.
Use of uninitialized value in split at /gnu/store/4x20lf98vwj357zcj6il8zka2d8mr9h0-inxi-minimal-3.0.20-1/bin/.inxi-real line 17535.
12System: 12Host ribbon 12Kernel 4.20.3-gnu x86_64 12bits 64 12Console N/A 12Distro unknown

Toggle quote (3 lines)
> That said, I'm happy enough to plop it in my own os-config and drop the
> patch.

OK, let’s take that route.

That said, I’m clearly opinionated ;-), but if that turns out to be a
hindrance to many, we can revisit this issue.

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 23 Jan 2019 01:59
control message for bug #34154
(address . control@debbugs.gnu.org)
87fttjheya.fsf@gnu.org
tags 34154 wontfix
close 34154
R
R
Ricardo Wurmus wrote on 23 Jan 2019 03:37
Re: [bug#34154] [PATCH] /etc/os-release
(name . Ludovic Courtès)(address . ludo@gnu.org)
87h8dz7gg5.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
>> It looks like some build systems can try to get information from it
>> during building if they have distro-specific things to do.
>
> That is precisely the kind of bad practice that I’d rather not
> encourage. :-)

Build systems doing this is bad, of course, but if this was a script
that tried to be helpful by telling the user what commands to run to
install dependencies I think it could be helpful.

(I have a vague memory of a project that tried to figure out how to
detect if the script is running on a Guix system by checking for
/run/current-system and the like.)

/etc/os-release would be a friendlier indicator than
/run/current-system.

--
Ricardo
N
N
ng0 wrote on 23 Jan 2019 06:32
(name . Ricardo Wurmus)(address . rekado@elephly.net)
20190123143203.3yqtklffr3twr35i@uptimegirl.lan
Ricardo Wurmus transcribed 722 bytes:
Toggle quote (17 lines)
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> >> It looks like some build systems can try to get information from it
> >> during building if they have distro-specific things to do.
> >
> > That is precisely the kind of bad practice that I’d rather not
> > encourage. :-)
>
> Build systems doing this is bad, of course, but if this was a script
> that tried to be helpful by telling the user what commands to run to
> install dependencies I think it could be helpful.
>
> (I have a vague memory of a project that tried to figure out how to
> detect if the script is running on a Guix system by checking for
> /run/current-system and the like.)

It was PyBitmessage.
Later on they realized this was a terrible idea.
Maybe we could have a documentation section for 'best practices'
to recommend against trying to detect Guix(SD) like this or
rather provide positive examples? It's not our job, but people
can get confused as PyBitmessage showed.
Toggle quote (10 lines)
> /etc/os-release would be a friendlier indicator than
> /run/current-system.
>
> --
> Ricardo
>
>
>
>
>
L
L
Ludovic Courtès wrote on 25 Jan 2019 00:42
(address . ng0@n0.is)
87womtruw1.fsf@gnu.org
Hello,

ng0@n0.is skribis:

Toggle quote (26 lines)
> Ricardo Wurmus transcribed 722 bytes:
>>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>> >> It looks like some build systems can try to get information from it
>> >> during building if they have distro-specific things to do.
>> >
>> > That is precisely the kind of bad practice that I’d rather not
>> > encourage. :-)
>>
>> Build systems doing this is bad, of course, but if this was a script
>> that tried to be helpful by telling the user what commands to run to
>> install dependencies I think it could be helpful.
>>
>> (I have a vague memory of a project that tried to figure out how to
>> detect if the script is running on a Guix system by checking for
>> /run/current-system and the like.)
>
> It was PyBitmessage.
> https://github.com/Bitmessage/PyBitmessage/commit/b7e75b9bc51e7036045167ad6191fe339f1a9daa#diff-2eeaed663bd0d25b7e608891384b7298
> Later on they realized this was a terrible idea.
> Maybe we could have a documentation section for 'best practices'
> to recommend against trying to detect Guix(SD) like this or
> rather provide positive examples? It's not our job, but people
> can get confused as PyBitmessage showed.

Interesting example. I’d argue that PyBitmessage is going too far by
trying to guess that commands the user should do—it’s bound to provide
inaccurate or outdated instructions at some point.

Anyway, I’m not strongly opposed to adding this file, but I think it
would help to have a couple of compelling examples. :-)

Thanks,
Ludo’.
A
A
Angelos Kapsimanis wrote on 5 Aug 2021 10:56
unarchive 34154
(name . control@debbugs.gnu.org)(address . control@debbugs.gnu.org)
36-bJau0GXybxv0BCxV-3SwgyEOOpj8KkmW1cRyfydTJzckzhn2zBRx8qNWri1qfgek9BgNRoZFA8pYKtdABNNnMnrBWTPvc2e1-dOYB5Yw=@protonmail.com
unarchive 34154
Attachment: file
M
M
Maxim Cournoyer wrote on 5 Aug 2021 20:06
Re: bug#34154: [PATCH] /etc/os-release
(name . Angelos Kapsimanis)(address . angelos.kapsimanis@protonmail.com)(address . 34154@debbugs.gnu.org)
87wnozl1an.fsf@gmail.com
Hello,

Angelos Kapsimanis <angelos.kapsimanis@protonmail.com> writes:

Toggle quote (2 lines)
> unarchive 34154

Why are you unarchiving this old, closed as wontfix bug? :-) Do you
disagree with the past resolution? We'd need some fresh arguments to
consider reopening it.

Thank you,

Maxim
M
M
Maxim Cournoyer wrote on 23 Feb 2022 21:16
control message for bug #34154
(address . control@debbugs.gnu.org)
87zgmgkfnx.fsf@gmail.com
close 34154
quit
B
B
bill-auger wrote on 29 Jun 2023 19:56
unarchive 34154
(address . control@debbugs.gnu.org)
20230629225628.23e851c6@parabola.localdomain
unarchive 34154
B
B
bill-auger wrote on 29 Jun 2023 20:05
Re: please re-consider adding an os-release file
(address . 34154@debbugs.gnu.org)
20230629230549.0242ef08@parabola.localdomain
please consider adding this file - aside from the specific use-cases which were
argued against on this thread; it is generally useful for any application that
has a valid reason to know which OS it is running on, without resorting to a
difficult-to-maintain stack of brittle white-box knowledge and system calls
like os-prober does - that identification can be used to infer the system's
properties which tend to differ across the *nix zoo, such as it's level of FHS
conformance, the name of the package manager executable, the bug reporting
URL, and so on

i am asking for the specific purpose of h-client, which has OS identification as
among it's primary purposes - guix is the only distro supported by h-node which
does not have an os-release file - nearly every distro in existence has adopted
this as the standard identifier, in favor of distro-specific files and clumsy
mechanisms such as lsb_release

the proposed patch was not quite compliant though - the standard is for the
actual file to be /usr/lib/os-release, with /etc/os-release being optional -
but if /etc/os-release exists, it should be a relative symlink to
../usr/lib/os-release - the reason is that applications should first check
/etc/os-release, in case it has been over-ridden by the local admin, then
fallback to checking the vendor-provided /usr/lib/os-release if /etc/os-release
is missing

with guix being as let's say "unconventional" as it is WRT the filesystem,
perhaps that was an important implementation detail; but please put at
least one, in one of those deterministic locations - even if no application
that guix distributes is known to make use of it, it is a completely harmless,
stable, and tiny file - rolling distros only need to add it once, and it will
never need an iota of maintenance
?
Your comment

This issue is archived.

To comment on this conversation send an email to 34154@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 34154
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch