Howdy, Miguel Ángel Arruga Vivas <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > >> Hi, >> >> Leo Famulari <[email protected]> skribis: >> >>> On Tue, Jan 05, 2021 at 03:36:07PM +0100, Miguel Ángel Arruga Vivas wrote: >>>> There are several binary formats that allow compression of the >>>> executable image, or some of its data, which is decompress at runtime: >>>> >>>> - Kernel images. >>>> - Compressed libraries: e.g. Smalltalk modules. >>>> - Compressed executable or data files: e.g. library.el.gz. >>>> >>>> These aren't taken into account by the grafting process, which may lead >>>> to issues when store paths are located inside that kind of files. >>> >>> If you have specific instances of this type of bug, please report them. >> >> Agreed. The general issue is “well known” as we say, but what I think >> we need to do is look for specific instances and address them. > > It can be tagged it notabug if you consider so. I've tagged it as > wishlist (I should have been done it before) for that reason (it's "well > known"), but I haven't found any specific instance yet. OTOH, I think > it might be closely related to #33848, as the solution for both issues > could be solved by the extension on the dumpPath code path---or the > Scheme implementation equivalent, as pointed there. Yes, though I’d prefer simple workarounds if possible—after all, we’ve lived with it since the beginning and there’s only ever been a handful of instances of that problem (one of them was really tricky, see ‘gcc-strmov-store-file-names.patch’…). Ludo’.
