GNU bug report logs - #34154
[PATCH] /etc/os-release

Previous Next

Package: guix-patches;

Reported by: Efraim Flashner <efraim <at> flashner.co.il>

Date: Mon, 21 Jan 2019 10:18:01 UTC

Severity: normal

Tags: patch, wontfix

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34154 in the body.
You can then email your comments to 34154 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Mon, 21 Jan 2019 10:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Efraim Flashner <efraim <at> flashner.co.il>:
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Mon, 21 Jan 2019 10:18:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: guix-patches <at> gnu.org
Subject: [PATCH] /etc/os-release
Date: Mon, 21 Jan 2019 12:17:40 +0200
[Message part 1 (text/plain, inline)]
Currently GuixSD ships without an '/etc/os-release' file. This simple
service aims to correct this.

-- 
Efraim Flashner   <efraim <at> 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
[0001-services-Add-os-release-file.patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Tue, 22 Jan 2019 21:39:02 GMT) Full text and rfc822 format available.

Message #8 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Tue, 22 Jan 2019 22:38:05 +0100
Hello!

Efraim Flashner <efraim <at> 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’.




Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Wed, 23 Jan 2019 07:21:01 GMT) Full text and rfc822 format available.

Message #11 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Wed, 23 Jan 2019 09:20:18 +0200
[Message part 1 (text/plain, inline)]
On Tue, Jan 22, 2019 at 10:38:05PM +0100, Ludovic Courtès wrote:
> Hello!
> 
> Efraim Flashner <efraim <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Wed, 23 Jan 2019 10:00:01 GMT) Full text and rfc822 format available.

Message #14 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Wed, 23 Jan 2019 10:59:26 +0100
Hello,

Efraim Flashner <efraim <at> 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’.




Added tag(s) wontfix. Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 23 Jan 2019 10:00:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 34154 <at> debbugs.gnu.org and Efraim Flashner <efraim <at> flashner.co.il> Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 23 Jan 2019 10:00:02 GMT) Full text and rfc822 format available.

Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Wed, 23 Jan 2019 11:39:01 GMT) Full text and rfc822 format available.

Message #21 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Efraim Flashner <efraim <at> flashner.co.il>, 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Wed, 23 Jan 2019 12:37:30 +0100
Ludovic Courtès <ludo <at> 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





Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Wed, 23 Jan 2019 14:33:02 GMT) Full text and rfc822 format available.

Message #24 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: ng0 <at> n0.is
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Wed, 23 Jan 2019 14:32:03 +0000
Ricardo Wurmus transcribed 722 bytes:
> 
> Ludovic Courtès <ludo <at> 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
> 
> 
> 
> 
> 




Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Fri, 25 Jan 2019 08:43:02 GMT) Full text and rfc822 format available.

Message #27 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: ng0 <at> n0.is
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 34154 <at> debbugs.gnu.org
Subject: Re: [bug#34154] [PATCH] /etc/os-release
Date: Fri, 25 Jan 2019 09:42:06 +0100
Hello,

ng0 <at> n0.is skribis:

> Ricardo Wurmus transcribed 722 bytes:
>> 
>> Ludovic Courtès <ludo <at> 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 archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 22 Feb 2019 12:24:05 GMT) Full text and rfc822 format available.

bug unarchived. Request was from Angelos Kapsimanis <angelos.kapsimanis <at> protonmail.com> to control <at> debbugs.gnu.org. (Thu, 05 Aug 2021 17:58:02 GMT) Full text and rfc822 format available.

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 05 Aug 2021 17:58:02 GMT) Full text and rfc822 format available.

Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Fri, 06 Aug 2021 03:07:01 GMT) Full text and rfc822 format available.

Message #36 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Angelos Kapsimanis <angelos.kapsimanis <at> protonmail.com>
Cc: 34154 <at> debbugs.gnu.org
Subject: Re: bug#34154: [PATCH] /etc/os-release
Date: Thu, 05 Aug 2021 23:06:24 -0400
Hello,

Angelos Kapsimanis <angelos.kapsimanis <at> 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




bug closed, send any further explanations to 34154 <at> debbugs.gnu.org and Efraim Flashner <efraim <at> flashner.co.il> Request was from Maxim Cournoyer <maxim.cournoyer <at> gmail.com> to control <at> debbugs.gnu.org. (Thu, 24 Feb 2022 05:17:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 24 Mar 2022 11:24:09 GMT) Full text and rfc822 format available.

bug unarchived. Request was from bill-auger <bill-auger <at> peers.community> to control <at> debbugs.gnu.org. (Fri, 30 Jun 2023 02:59:01 GMT) Full text and rfc822 format available.

Information forwarded to guix-patches <at> gnu.org:
bug#34154; Package guix-patches. (Fri, 30 Jun 2023 03:08:01 GMT) Full text and rfc822 format available.

Message #45 received at 34154 <at> debbugs.gnu.org (full text, mbox):

From: bill-auger <bill-auger <at> peers.community>
To: 34154 <at> debbugs.gnu.org
Subject: Re: please re-consider adding an os-release file
Date: Thu, 29 Jun 2023 23:05:49 -0400
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




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 28 Jul 2023 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 245 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.