From: "Ludovic Courtès" <ludo@gnu.org>
To: Timothy Sample <samplet@ngyro.com>
Cc: 52828@debbugs.gnu.org
Subject: [bug#52828] [PATCH] Fix Disarchive fallback on Guix System
Date: Sat, 15 Jan 2022 22:33:21 +0100 [thread overview]
Message-ID: <87a6fw3cri.fsf_-_@gnu.org> (raw)
In-Reply-To: <8735lpxbd1.fsf_-_@ngyro.com> (Timothy Sample's message of "Sat, 15 Jan 2022 10:33:14 -0500")
Hi,
Timothy Sample <samplet@ngyro.com> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> What about uses of guix-daemon on other distros? Perhaps we assume tar
>> and gzip are already on PATH?
>
> That’s my guess. And if those other weird distros don’t have ‘tar’ and
> ‘gzip’ in “/usr/bin”, I’m sure they’re plenty accustomed to liberally
> patching their packages. ;)
True.
>> I’d feel more comfortable with a solution at the package level. In the
>> ‘guix’ package, or perhaps in a Makefile.am, we could hard-code absolute
>> file names of tar and gzip in (guix scripts perform-download) and set
>> PATH from there. We’d need to do the same in (guix self) though.
>>
>> Alternatively, we could change (guix swh) to use Guile-Zlib and the tar
>> implementation of Gash-Utils or that of Disarchive.
>>
>> WDYT?
>
> I’ve attached a new patch that mixes those two suggestions but gets the
> first one a little wrong. It uses the absolute path for ‘tar’, but uses
> Guile-zlib for decompression.
>
> I honestly don’t have a strong opinion about when and where to set
> ‘$PATH’ vs. using a configured, absolute path. My original patch
> assumed that it’s the user’s job to make sure that ‘tar’ and ‘gzip’ are
> available to Guix at runtime. This patch assumes that that linkage
> happens at configure time. The main benefit I could see to setting
> ‘$PATH’ in ‘(guix scripts perform-download)’ is that we could add our
> ‘tar’ and ‘gzip’ as a suffix. This makes it work while allowing users
> to choose whatever ‘tar’ and ‘gzip’ they prefer. The downside is that
> whenever we use ‘(guix swh)’ have to remember to make sure that ‘tar’
> and ‘gzip’ are available.
>
> Basically, I can to change this to do the setup in ‘perform-download’,
> but I really want to understand why.
Hmm yes, I guess you’re right, I prefer the initial patch after all.
(In particular I’m not keen on adding things to (guix config).)
Go for it?
Longer-term, I think it would still be interesting to migrate to
Guile-Zlib + Disarchive/Gash-Utils, but we can check that later—better
fix the Disarchive fallback first.
Thanks and sorry for the hesitations!
Ludo’.
next prev parent reply other threads:[~2022-01-15 21:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-27 18:39 [bug#52828] [PATCH] Fix Disarchive fallback on Guix System Timothy Sample
2022-01-05 20:54 ` Ludovic Courtès
2022-01-15 15:33 ` [bug#52828] [PATCH v2] swh: Do not rely on $PATH for tar and gzip Timothy Sample
2022-01-15 21:33 ` Ludovic Courtès [this message]
2022-01-17 1:00 ` bug#52828: [PATCH] Fix Disarchive fallback on Guix System Timothy Sample
2022-01-17 13:11 ` [bug#52828] " Ludovic Courtès
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=87a6fw3cri.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=52828@debbugs.gnu.org \
--cc=samplet@ngyro.com \
/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).