From: "Clément Lassieur" <clement@lassieur.org>
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: 32102@debbugs.gnu.org
Subject: [bug#32102] [PATCH] utils: Fix wrap-program filename generation.
Date: Mon, 09 Jul 2018 16:12:31 +0200 [thread overview]
Message-ID: <87r2kc8pm8.fsf@lassieur.org> (raw)
In-Reply-To: <cu7efgcn0pg.fsf@systemreboot.net>
Arun Isaac <arunisaac@systemreboot.net> writes:
>>> * guix/build/utils.scm (wrap-program): While generating a new filename for the
>>> wrapped program, trim dots from the left of the basename. This prevents
>>> already wrapped files being wrapped again with two or more dots prepended to
>>> them.
>>
>> Why is it a problem that two or more dots are prepended to them?
>
> (define (wrap-program prog #:rest vars)
> (define wrapped-file
> (string-append
> (dirname prog) "/." (basename prog) "-real"))
>
> (define already-wrapped?
> (file-exists? wrapped-file))
>
> ...)
>
> If wrap-program finds that PROG has previously been wrapped, it extends
> the wrapper; it does not create a wrapper around the previously existing
> wrapper (a "double wrapper"). wrap-program detects that PROG has
> previously been wrapped by comparing the expected wrapped filename (see
> code snippet above). Without the string-trim I added, this
> already-wrapped? detection fails and a double wrapper ends up being
> created.
If '.gajim-real' exists and (WRAP-PROGRAM '/path/to/gajim' ...) is
called, PROG is '/path/to/gajim', WRAPPED-FILE is '/path/to/.gajim-real'
and ALREADY-WRAPPED? is #t, so I don't think there is a bug with
WRAP-PROGRAM.
The ..gajim-real-real file comes from the WRAP procedure in
python-build-system.scm: that WRAP procedure wraps every file it finds.
It'll wrap '.gajim-real' and 'gajim'. Wrapping 'gajim' will work well,
it will be modified because it's already a wrapper, i.e. '.gajim-real'
exists. But wrapping '.gajim-real' will create '..gajim-real-real'
because '.gajim-real' is not a wrapper. And I think it's normal too.
So the question is: should WRAP (from python-build-system.scm) wrap
files that already have a wrapper? I think it shouldn't.
Clément
next prev parent reply other threads:[~2018-07-09 14:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 1:31 [bug#32102] [PATCH] utils: Fix wrap-program filename generation Arun Isaac
2018-07-09 7:35 ` Clément Lassieur
2018-07-09 10:49 ` Arun Isaac
2018-07-09 14:12 ` Clément Lassieur [this message]
2018-07-10 5:16 ` Arun Isaac
2018-07-10 8:57 ` Clément Lassieur
2018-07-10 18:13 ` Mark H Weaver
2018-07-11 19:26 ` [bug#32102] [PATCH v2 0/2] build-system: python: Only wrap non-hidden executable files Arun Isaac
2018-07-11 19:26 ` [bug#32102] [PATCH v2 1/2] " Arun Isaac
2018-07-13 7:42 ` Clément Lassieur
2018-07-13 8:35 ` Arun Isaac
2018-07-11 19:26 ` [bug#32102] [PATCH v2 2/2] gnu: gajim: Combine wrap-program phases Arun Isaac
2018-07-13 8:38 ` Clément Lassieur
2018-07-13 9:45 ` Arun Isaac
2018-07-28 20:42 ` Arun Isaac
2018-07-29 14:20 ` Ludovic Courtès
2018-07-30 0:30 ` Arun Isaac
2018-08-27 11:37 ` Ludovic Courtès
2018-08-28 8:37 ` Arun Isaac
2018-08-29 20:42 ` Ludovic Courtès
2018-11-22 16:54 ` Arun Isaac
2018-11-23 9:09 ` Ludovic Courtès
2018-11-27 10:43 ` bug#32102: " Arun Isaac
2018-11-27 12:24 ` [bug#32102] " Clément Lassieur
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=87r2kc8pm8.fsf@lassieur.org \
--to=clement@lassieur.org \
--cc=32102@debbugs.gnu.org \
--cc=arunisaac@systemreboot.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.