[bug#34154] /etc/os-release

Currently GuixSD ships without an '/etc/os-release' file. This simple
service aims to correct this.

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

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

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

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

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

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