all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Fredrik Salomonsson <plattfot@posteo.net>
Cc: 45190@debbugs.gnu.org
Subject: [bug#45190] [PATCH 0/1] Add pinentry-rofi
Date: Wed, 13 Jan 2021 16:24:56 +0100	[thread overview]
Message-ID: <875z4097w7.fsf_-_@gnu.org> (raw)
In-Reply-To: <878s926emu.fsf@posteo.net> (Fredrik Salomonsson's message of "Fri, 08 Jan 2021 18:14:01 -0800")

Hi,

Fredrik Salomonsson <plattfot@posteo.net> skribis:

>>> +  (arguments
>>> +    `(#:strip-binaries? #f ;; Has no binaries and the strip phase is failing
>>
>> Hmm the ‘strip’ phase should not fail.  Are you sure this is necessary?
>
> It was failing with a warning as there are no binaries to strip. But
> it's not an error so I removed this in v2.

Right, it’s just a warning, due to the fact that .go files are ELF but
the ‘strip’ command doesn’t know what to do with them.

>> Since I think you’re also upstream :-), how about adding something like
>> that at the top of the installed executable:
>>
>>   (eval-when (load expand eval)
>>     (set! %load-path (cons "@moddir@" %load-path))
>>     (set! %laod-compiled-path (cons "@godir@" %load-compiled-path)))
>>
>> ?
>
> Yup, I'm upstream as well. I don't mind adding that, just need to know
> what it solves :). I'm guessing that it removes the need to wrap the
> executable, is that correct?
>
> And are the "@moddir@" and "@godir@" expected to be expanded by
> automake? I tested to just add it in the source code and automake did
> nothing with them.

It’s replaced provided ‘configure.ac’ defines them and AC_SUBSTs them,
along these lines (here they have a longer name):

  https://notabug.org/guile-zstd/guile-zstd/src/master/configure.ac#L43

>> It’s best to avoid propagating.  Perhaps you can replace the “rofi”
>> string in ‘pinentry-rofi’ by “/gnu/store/…/bin/rofi” in a post-install
>> phase?
>
> Is there a rule of thumb or something to know when to use propagating
> inputs? I'm a bit confused when to use is it. Is it just when dealing
> with libraries? What are the downsides of using propagating inputs?
> Apologize if this is already mentioned in the manual. Only sections I
> could find that mentions propagated inputs are section 5.2 and 8.2.1.

In general, propagated inputs should be avoided as they “pollute” the
user’s profile (you install X and find yourself with X, Y, and Z).

The preferred method in situations like this is to patch the source so
it uses absolute file names for commands.

Thanks for sending an updated patch!

Ludo’.




  reply	other threads:[~2021-01-13 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12  2:19 [bug#45190] [PATCH 0/1] Add pinentry-rofi Fredrik Salomonsson
2020-12-12  2:31 ` [bug#45190] [PATCH 1/1] gnu: " Fredrik Salomonsson
2021-01-03 21:18   ` Ludovic Courtès
2021-01-09  2:14     ` Fredrik Salomonsson
2021-01-13 15:24       ` Ludovic Courtès [this message]
2021-01-09  1:47 ` [bug#45190] [PATCH v2] " Fredrik Salomonsson
2021-01-13 15:26   ` bug#45190: [PATCH 0/1] " 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

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

  git send-email \
    --in-reply-to=875z4097w7.fsf_-_@gnu.org \
    --to=ludo@gnu.org \
    --cc=45190@debbugs.gnu.org \
    --cc=plattfot@posteo.net \
    /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.