unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Philip McGrath" <philip@philipmcgrath.com>
To: "Liliana Marie Prikler" <liliana.prikler@gmail.com>,
	"Maxime Devos" <maximedevos@telenet.be>,
	guix-devel@gnu.org
Subject: Re: The case for moving raw binaries
Date: Fri, 29 Jul 2022 17:20:04 -0400	[thread overview]
Message-ID: <21016dde-9075-43b2-a539-e72967f55603@www.fastmail.com> (raw)
In-Reply-To: <34fac706c704d5ab01a067c20f0d1407a1f7e565.camel@gmail.com>

Hi,

On Fri, Apr 29, 2022, at 12:59 PM, Liliana Marie Prikler wrote:
> Am Freitag, dem 29.04.2022 um 11:27 +0200 schrieb Maxime Devos:
>> [...]
>> 
>> I thought that
>> 
>>   (if already-wrapped?
>>       ;; PROG is already a wrapper: add the new "export VAR=VALUE"
>>       ;; lines just before the last line.
>>       [...])
>> 
>> in 'wrap-program' would avoid creating ..foo-real-real?
> You are correct, I was going on old info that I haven't checked since.
>
> This leaves us with
>> That said, the proposed new behaviour seems reasonable to me --
>> "pidof emacs" would then actually find Emacs.
> and the annoyance that "." shell-completes to all the wrapped binaries.
> For the former, there is IIRC still a bug in tramp (and I'm sure other
> emacs packages), because a process name doesn't match the expected
> regexp.
>
> As for where to move things, I'm starting to lean a little closer
> towards having an own output.  That way, we don't need to worry about
> stuff from different directories (e.g. bin and sbin) shadowing each
> other (even though that shouldn't occur), but more importantly, if we
> need to copy data into rawbin so that it's correctly resolved, we can
> do that.  The only thing that doesn't quite work is relative resolution
> of commands, which would go through the wrapper-less binaries instead.
> However, given that the wrapperless binary is invoked from a wrapped
> binary, I am 73.69% certain, that this ought not to create too much of
> a problem w.r.t. the set environment variables.
>
> WDYT?

I was mildly annoyed recently with several programs that use the ".foo-real" name in their `--help` output, for example:

```
$ guix shell --pure reuse -- reuse -h
usage: .reuse-real [-h] [--debug] [--include-submodules]
```

I wondered about just changing `wrap-program` to put the real program at `.real/foo` instead of `.foo-real`. One advantage is that it wouldn't need any special cooperation like setting up an output or an environment variable.

-Philip


  reply	other threads:[~2022-07-29 21:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 16:37 The case for moving raw binaries Liliana Marie Prikler
2022-04-28 16:50 ` Maxime Devos
2022-04-28 16:55 ` Maxime Devos
2022-04-28 17:27   ` Liliana Marie Prikler
2022-04-28 19:57     ` Maxime Devos
2022-04-28 22:52       ` raingloom
2022-04-29  9:39         ` Maxime Devos
2022-04-29  4:13       ` Liliana Marie Prikler
2022-04-29  9:27         ` Maxime Devos
2022-04-29 16:59           ` Liliana Marie Prikler
2022-07-29 21:20             ` Philip McGrath [this message]
2022-07-30  6:11               ` Liliana Marie Prikler
2022-08-04  8:54                 ` Ludovic Courtès
2022-08-04 16:53                   ` Liliana Marie Prikler
2022-04-29  9:18 ` zimoun
2022-05-23 15:10 ` Ludovic Courtès
2022-05-23 16:03   ` Maxime Devos
2022-05-23 16:37   ` Liliana Marie Prikler

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=21016dde-9075-43b2-a539-e72967f55603@www.fastmail.com \
    --to=philip@philipmcgrath.com \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=maximedevos@telenet.be \
    /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).