all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: bill-auger <bill-auger@peers.community>
To: 34154@debbugs.gnu.org
Subject: [bug#34154] please re-consider adding an os-release file
Date: Thu, 29 Jun 2023 23:05:49 -0400	[thread overview]
Message-ID: <20230629230549.0242ef08@parabola.localdomain> (raw)
In-Reply-To: <20230629224119.0dea87db@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




           reply	other threads:[~2023-06-30  3:08 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20230629224119.0dea87db@parabola.localdomain>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230629230549.0242ef08@parabola.localdomain \
    --to=bill-auger@peers.community \
    --cc=34154@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.