[bug#34154] [PATCH] /etc/os-release

[bug#34154] [PATCH] /etc/os-release

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 315 bytes --]

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

[-- Attachment #1.2: 0001-services-Add-os-release-file.patch --]
[-- Type: text/plain, Size: 1753 bytes --]

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(+)

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")))
+
 \f
 (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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#34154] [PATCH] /etc/os-release

[Ludovic Courtès]

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?

Thanks,
Ludo’.

[bug#34154] [PATCH] /etc/os-release

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Tue, Jan 22, 2019 at 10:38:05PM +0100, Ludovic Courtès wrote:
> 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.

¹https://www.freedesktop.org/software/systemd/man/os-release.html

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#34154] [PATCH] /etc/os-release

[Ludovic Courtès]

Hello,

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

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

OK.

> 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.  :-)

> 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:

--8<---------------cut here---------------start------------->8---
$ 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 
--8<---------------cut here---------------end--------------->8---

> 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’.

[bug#34154] [PATCH] /etc/os-release

[Ricardo Wurmus]

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.)

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

--
Ricardo

[bug#34154] [PATCH] /etc/os-release

[ng0]

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.
 
> /etc/os-release would be a friendlier indicator than
> /run/current-system.
> 
> --
> Ricardo
> 
> 
> 
> 
> 

[bug#34154] [PATCH] /etc/os-release

[Ludovic Courtès]

Hello,

ng0@n0.is skribis:

> 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’.

[bug#34154] [PATCH] /etc/os-release

[Maxim Cournoyer]

Hello,

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

> 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