[bug#39146,v2] gnu: icecat: Remove compiler paths from about:buildconfig

* gnu/packages/gnuzilla.scm
  (icecat)[arguments](dont-store-compiler-paths): New phase.
---
 gnu/packages/gnuzilla.scm | 11 +++++++++++
 1 file changed, 11 insertions(+)

Hi Mark,

since we have to touch Rust anyway, the icecat patch from Jakub below could also
go to guix staging.

Is the patch OK?  Should we do it?

Jakub,

Jakub Kądziołka 写道：
> +         (add-after 'unpack 'dont-store-compiler-paths
> +           (lambda _
> +             ;; Remove references to the compilers used from 
> the output. Reduces
> +             ;; `guix size icecat' by 1 GiB on x86-64.
> +             (let ((zap "Store reference removed"))
> +               (substitute* "toolkit/content/buildconfig.html"
> +                 (("@CC@") zap)
> +                 (("@CXX@") zap)
> +                 (("@RUSTC@") zap)
> +                 (("@MOZ_CONFIGURE_OPTIONS@") zap)))))

Thanks!  This is a fine fix, but I wonder if you know where/how 
this file is processed by the build system?  I think scanning for 
and neutralising any store reference in the final HTML would be 
less error-prone.

Thoughts?

Kind regards,

T G-R

Hi Danny,

Thanks for checking in with me on this.

> since we have to touch Rust anyway, the icecat patch from Jakub below could also
> go to guix staging.
> 
> Is the patch OK?  Should we do it?

Instead of removing the build configuration information entirely, how
about transforming the store paths in some way that makes them invisible
to the reference scanner without losing information?  For example,
inserting a period (.) somewhere within the store hash would be
sufficient and fairly obvious.

What do you think?

Also, the new phase should end with #t.

     Thanks,
       Mark

On Wed, Jan 22, 2020 at 04:23:31PM -0500, Mark H Weaver wrote:
> Hi Danny,
> 
> Thanks for checking in with me on this.
> 
> > since we have to touch Rust anyway, the icecat patch from Jakub below could also
> > go to guix staging.
> > 
> > Is the patch OK?  Should we do it?
> 
> Instead of removing the build configuration information entirely, how
> about transforming the store paths in some way that makes them invisible
> to the reference scanner without losing information?  For example,
> inserting a period (.) somewhere within the store hash would be
> sufficient and fairly obvious.
> 
> What do you think?
It wasn't clear to me how to transform the paths after they get
substituted, but nckx has suggested a better approach:
https://debbugs.gnu.org/39146

Regards,
Jakub Kądziołka

I like the approach of Tobias' proposed patch, but to avoid losing
information (most of the hash), how about changing:

  (string-append store (string-take hash 8) "…")

to something like:

  (string-append store (string-take hash 2) "." (string-drop hash 2))

What do you think?  Anyway, I don't feel strongly about it, and I
acknowledge that neither approach is perfect.

      Regards,
        Mark

On Thu, Jan 23, 2020 at 09:53:48PM -0500, Mark H Weaver wrote:
> I like the approach of Tobias' proposed patch, but to avoid losing
> information (most of the hash), how about changing:
> 
>   (string-append store (string-take hash 8) "…")
> 
> to something like:
> 
>   (string-append store (string-take hash 2) "." (string-drop hash 2))
> 
> What do you think?  Anyway, I don't feel strongly about it, and I
> acknowledge that neither approach is perfect.
I feel like the unicode character "…" makes it much more clear that the
path has been modified, but it's a moot point considering that if
someone might get confused by this, they probably won't be able to make
use of the hash.

However, now that I come back to this after some time, I realize that
there is another solution:

    (string-append store (string-take hash 8) "<span></span>"
                         (string-drop hash 8))

This would neuter the reference without having any user-visible impact on
about:buildconfig. What do you think?

Kind regards,
Jakub Kądziołka

Hi Jakub,

Jakub Kądziołka <kuba@kadziolka.net> wrote:
> However, now that I come back to this after some time, I realize that
> there is another solution:
> 
>     (string-append store (string-take hash 8) "<span></span>"
>                          (string-drop hash 8))
> 
> This would neuter the reference without having any user-visible impact on
> about:buildconfig. What do you think?

Great idea, I think this is the right approach.  Would you like to
propose a patch and test it?

    Thank you!
       Mark

Jakub, all,

On Mon, Feb 10, 2020 at 7:38 PM, Jakub =?UTF-8?b?S8SFZHppb8WCa2E=?= 
<kuba@kadziolka.net> wrote:
> On Thu, Jan 23, 2020 at 09:53:48PM -0500, Mark H Weaver wrote:
>>  I like the approach of Tobias' proposed patch, but to avoid losing
>>  information (most of the hash), how about changing:
>> 
>>    (string-append store (string-take hash 8) "…")
>> 
>>  to something like:
>> 
>>    (string-append store (string-take hash 2) "." (string-drop hash 
>> 2))
>> 
>>  What do you think?  Anyway, I don't feel strongly about it, and I
>>  acknowledge that neither approach is perfect.
> I feel like the unicode character "…" makes it much more clear that 
> the
> path has been modified, but it's a moot point considering that if
> someone might get confused by this, they probably won't be able to 
> make
> use of the hash.
> 
> However, now that I come back to this after some time, I realize that
> there is another solution:
> 
>     (string-append store (string-take hash 8) "<span></span>"
>                          (string-drop hash 8))
> 
> This would neuter the reference without having any user-visible 
> impact on
> about:buildconfig. What do you think?

The truncation of these very long paths was fully intended as a 
feature, but if people do think they're actually useful I think this is 
a clever hack worthy of Guix :-)

Have you tested whether copying & pasting still works fine with this?

Kind regards,

T G-R, adrift without mu4e