unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: ng0@n0.is
Cc: 34154@debbugs.gnu.org
Subject: [bug#34154] [PATCH] /etc/os-release
Date: Fri, 25 Jan 2019 09:42:06 +0100	[thread overview]
Message-ID: <87womtruw1.fsf@gnu.org> (raw)
In-Reply-To: <20190123143203.3yqtklffr3twr35i@uptimegirl.lan> (ng0's message of "Wed, 23 Jan 2019 14:32:03 +0000")

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

  reply	other threads:[~2019-01-25  8:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 10:17 [bug#34154] [PATCH] /etc/os-release Efraim Flashner
2019-01-22 21:38 ` Ludovic Courtès
2019-01-23  7:20   ` Efraim Flashner
2019-01-23  9:59     ` Ludovic Courtès
2019-01-23 11:37       ` Ricardo Wurmus
2019-01-23 14:32         ` ng0
2019-01-25  8:42           ` Ludovic Courtès [this message]
     [not found] <36-bJau0GXybxv0BCxV-3SwgyEOOpj8KkmW1cRyfydTJzckzhn2zBRx8qNWri1qfgek9BgNRoZFA8pYKtdABNNnMnrBWTPvc2e1-dOYB5Yw=@protonmail.com>
2021-08-06  3:06 ` Maxim Cournoyer

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87womtruw1.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=34154@debbugs.gnu.org \
    --cc=ng0@n0.is \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).