From: ludo@gnu.org (Ludovic Courtès)
To: Thomas Danckaert <post@thomasdanckaert.be>
Cc: guix-devel@gnu.org
Subject: Re: store reference detection (was Re: JARs and reference scanning)
Date: Thu, 27 Apr 2017 15:46:59 +0200 [thread overview]
Message-ID: <87fugu6jzg.fsf@gnu.org> (raw)
In-Reply-To: <20170426.135333.1620868924745053745.post@thomasdanckaert.be> (Thomas Danckaert's message of "Wed, 26 Apr 2017 13:53:33 +0200 (CEST)")
Hello,
Thomas Danckaert <post@thomasdanckaert.be> skribis:
> From: Chris Marusich <cmmarusich@gmail.com>
> Subject: Re: JARs and reference scanning
> Date: Tue, 25 Apr 2017 22:34:02 -0700
>
>>> I have to admit that I do not know at all how the reference
>>> scanning and
>>> dependency-tracking in the store works.
>>
>> As I understand it, the mechanism used by the Guix daemon (and the
>> Nix
>> daemon) for scanning references doesn't work when the output of a
>> derivation is scrambled in some way (e.g. compressed). Therefore,
>> if we
>> use JAR files, they should not be compressed.
>
> The code scanning for reference is in nix/libstore/references.cc . It
> looks for base32 hashes encoded as character strings in the binaries.
>
> Could/should this be generalized somehow? Apart from compression,
> store filenames encoded with 16-bit character encodings also cause
> problems (can happen with Qt or WxWidgets). And the are probably more
> cases where it fails.
Really? Qt/WxWidgets “hide” store references by default?
> Does it make sense to expand the reference detecting code (perhaps
> this would lead to too many different special cases?), or maybe
> provide a mechanism to force references when the daemon cannot detect
> them. I suppose you can always add a text file with a list of store
> items to the output, but maybe there's a more elegant way?
‘propagated-inputs’ is one way to manually specify run-time references.
It works at the package level and not at the store level—that is, the
store item’s references are unaffected by what ‘propagated-inputs’
contains. It’s usually enough for our purposes though.
In that sense, I think jars are comparable to Python/Perl libraries,
which do not carry reference information by themselves and thus need a
manually-provided ‘propagated-inputs’.
WDYT?
Ludo’.
next prev parent reply other threads:[~2017-04-27 13:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 11:29 Need help from Java-developers Hartmut Goebel
2017-04-23 8:41 ` Chris Marusich
2017-04-23 22:57 ` Chris Marusich
2017-04-25 19:28 ` JARs and reference scanning (was: Need help from Java-developers) Hartmut Goebel
2017-04-26 5:34 ` JARs and reference scanning Chris Marusich
2017-04-26 11:53 ` store reference detection (was Re: JARs and reference scanning) Thomas Danckaert
2017-04-26 19:31 ` Maxim Cournoyer
2017-04-27 13:46 ` Ludovic Courtès [this message]
2017-04-27 14:14 ` store reference detection Thomas Danckaert
2017-04-27 17:46 ` store reference detection (was Re: JARs and reference scanning) Hartmut Goebel
2017-05-02 12:43 ` Ludovic Courtès
2017-05-07 12:48 ` Hartmut Goebel
2017-05-07 20:23 ` Chris Marusich
2017-05-08 7:06 ` Ricardo Wurmus
2017-05-08 14:11 ` Ludovic Courtès
2017-05-11 8:41 ` Chris Marusich
2017-05-11 11:27 ` Ricardo Wurmus
2017-05-12 6:54 ` Chris Marusich
2017-05-12 8:21 ` Ricardo Wurmus
2017-05-12 9:35 ` Hartmut Goebel
2017-05-12 18:22 ` Mark H Weaver
2017-05-12 20:05 ` Hartmut Goebel
2017-05-12 21:24 ` Mark H Weaver
2017-05-12 6:18 ` Mark H Weaver
2017-05-12 8:19 ` Chris Marusich
2017-05-12 9:46 ` store reference detection Hartmut Goebel
2017-05-12 17:39 ` store reference detection (was Re: JARs and reference scanning) Mark H Weaver
2017-05-12 18:27 ` Leo Famulari
2017-05-12 19:54 ` Hartmut Goebel
2017-05-12 21:51 ` Mark H Weaver
2017-05-13 7:15 ` Hartmut Goebel
2017-05-23 7:29 ` Chris Marusich
2017-04-25 8:44 ` Need help from Java-developers Ricardo Wurmus
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=87fugu6jzg.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=post@thomasdanckaert.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 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.