Re: Firefox 52's end of life, packaging Icecat 60

[Mark H Weaver <mhw@netris.org>]

Hi Clément,

Clément Lassieur <clement@lassieur.org> writes:

> As this blog article[1] says, Firefox 52's end of life will happen on
> August 28, 2018.  That is, in 47 days.  I imagine that by that time
> Icecat 60 will be released, but it seems that we are pretty far from
> being able to package it, because of the Rust packages that are needed.
> There might be other technical difficulties that I'm not aware of,
> though.
>
> Is there any plan in this regard?  Maybe, as a first step, we should
> list the required dependencies so that people can pick them up?  My
> understanding of that article[2] is that the top level dependencies are
> listed in Cargo.toml[3].
>
> What is the current state of the Rust build system (cargo-build-system)?
> Is there anything blocking that would prevent its use?  I'm asking
> because I see very few packages in gnu/packages/rust.scm.
>
> Thank you,
> Clément
>
> [1]: https://blog.mozilla.org/futurereleases/2018/01/11/announcing-esr60-policy-engine/
> [2]: https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code
> [3]: https://dxr.mozilla.org/mozilla-central/source/toolkit/library/rust/shared/Cargo.toml

Thanks for looking into this, and for raising the issue.  If you, or
someone else, would like to take the lead on this, I would be grateful.

For now, I would suggest trying to package upstream Firefox ESR 60.
Although we cannot add Firefox itself to Guix, IceCat 60 will be almost
identical to Firefox ESR 60, so we should be able to simply drop it in
when it becomes available.

To simplify things initially, you could comment out some or all of the
patches, snippet code, configure flags, and phases which try to avoid
bundled libraries and to use system libraries instead.  However, I would
not assume that commenting *all* of that out will help.  It's possible
that some of the bundled libraries won't work as-is on Guix because of
our unusual filesystem layout, whereas our corresponding system
libraries have already been patched to address those issues.
Alternatively, any needed patches and/or substitutions from our system
libraries could be applied to the corresponding bundled libraries.

The 'link-libxul-with-libraries' phase could also be commented out
temporarily, and instead you could manually set LD_LIBRARY_PATH as
needed before launching Firefox, so that it can find the shared
libraries it needs.

Any of these temporary solutions would be fine for now.  If you run into
difficulties, I would be glad to take a look.

If you can get Firefox ESR 60 working with the above simplifications,
then I would be glad to work on avoiding the bundled libraries, adapting
the 'link-libxul-with-libraries' phase, and swapping in IceCat 60.

What do you think?

      Mark