unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Jack Hill <jackhill@jackhill.us>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: 47180@debbugs.gnu.org
Subject: [bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files.
Date: Tue, 16 Mar 2021 01:43:05 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2103160038330.8138@marsh.hcoop.net> (raw)
In-Reply-To: <20210316025632.9767-1-philip@philipmcgrath.com>

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

Wow, that was speedy. Thanks for the care you've taken thinking about these 
issues. I've tested applying and building this patch and it works!

(Now that DrRacket starts it appears that I may have a font issue with it. 
I'll investigate more an open a separate bug if so.)

I don't think I know enough about Guix or Racket internals to give it a 
proper review or judge whether this will be robust against future grafting 
problems, but I do have a few comments


`git am` complained about the following, but I can't spot them looking at 
the patch.

.git/rebase-apply/patch:83: trailing whitespace.

.git/rebase-apply/patch:100: trailing whitespace.

.git/rebase-apply/patch:122: trailing whitespace.
-- 
.git/rebase-apply/patch:124: new blank line at EOF.


On Mon, 15 Mar 2021, Philip McGrath wrote:

> Apparently, during grafting, Guix can somehow mangle compiled
> Racket CS files (.zo) such that Racket will refuse to load them.
> (Maybe it has something to do with compression?)
> So, we stop patching Racket sources with absolute paths to store
> files (i.e. for foreign libraries to dlopen).
> Instead, we put them in a data file that doesn't get compiled or,
> in one case, embed it in C.

[…]

> +Guix should enable the special case by defining the C preprocessor
> +macro `GUIX_RKTIO_PATCH_BIN_SH` with the path to `sh` in the store.
> +If:
> +
> +    1. The `GUIX_RKTIO_PATCH_BIN_SH` macro is defined; and
> +
> +    2. `rktio_process` is called with the exact path "/bin/sh"; and
> +
> +    3. "/bin/sh" does not exist (if it does, we don't want to change
> +       the expected behavior); and

Do we really want #3? That would have a different effect than the current 
patching behavior intends. /bin/sh is present by default on Guix System, 
and likely to be present of foreign distros. I think in generally we like 
to avoid this dynamic binding and instead use the sh that was included as 
a package input.

> +    4. The path specified by `GUIX_RKTIO_PATCH_BIN_SH` does exists;
> +
> +then `rktio_process` will execute the file specified
> +by `GUIX_RKTIO_PATCH_BIN_SH` instead of "/bin/sh".
> +
> +Compared to previous attempts to patch the Racket sources,
> +making this change at the C level is both:
> +
> +    - More comprehensive: it catches all attempts to execute "/bin/sh",
> +      without having to track down the source of every occurance; and
> +
> +    - Less intrusive: by guarding the special case with a C preprocessor
> +      conditional and a runtime check that the file in the store exists,
> +      we make it much less likely that it will "leak" out of Guix.

Again, I might be wrong by preferring to always avoid /bin/sh even when 
it's available. Hopefully someone more knowledgeable will come along.

Best,
Jack

  reply	other threads:[~2021-03-16  5:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16  2:56 [bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files Philip McGrath
2021-03-16  5:43 ` Jack Hill [this message]
2021-03-16 17:37   ` Philip McGrath
2021-03-17  3:20     ` Jack Hill
2021-03-19  2:34       ` [bug#47180] [PATCH v2] " Philip McGrath
2021-04-12 16:48         ` bug#47180: [PATCH] " Ludovic Courtès
2021-04-10 20:59 ` [bug#47180] " Ludovic Courtès
2021-04-12  3:40   ` Philip McGrath
2021-04-12 12:55     ` Ludovic Courtès
2021-04-12 12:55     ` Ludovic Courtès
2021-04-16 20:16       ` Philip McGrath
2021-04-17 10:12         ` 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=alpine.DEB.2.21.2103160038330.8138@marsh.hcoop.net \
    --to=jackhill@jackhill.us \
    --cc=47180@debbugs.gnu.org \
    --cc=philip@philipmcgrath.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).