bug#32026: [PATCH 03/10] gnu: Define UPSTREAM-FIREFOX-SOURCE at the top level.

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> * gnu/packages/gnuzilla.scm (%icecat-base-version): New variable.
>> (%upstream-firefox-version): Likewise.
>> (%icecat-version): Define in terms of %icecat-base-version.
>> (upstream-firefox-source): New variable.
>> (icecat-source): Adjust to use the above newly introduced variables.
>
> I'm deeply uncomfortable binding toplevel variables, even unexported
> ones, that provide non-FSDG-complaint software.  I guess that the
> primary motivation for this commit was to make it easier to use the
> 'update-mozilla-locales' helper.

While I appreciate your concern, I think "hiding" the upstream source
would be akin to putting our head in the sand.  We do need that upstream
source to produce GNU IceCat from source, so it may as well be
convenient to handle while hacking on the GNU IceCat package.  As you've
noted, it isn't exported, so I think it'd be a stretch to say that this
private binding "steers" users toward non-FSDG software.  Note that we
also have a %upstream-linux-source procedure in (gnu packages linux).

> In an earlier message <https://bugs.gnu.org/32026#100>, I suggested an
> alternative way to use the code in your proposed
> 'update-mozilla-locales' helper which would eliminate the need to expose
> any *firefox* toplevel variables.  I hope you'll find that alternative
> approach acceptable, so that we can avoid exposing non-FSDG-compliant
> software in our toplevel bindings.
>
> What do you think?

See my explanation there that the need to maintain the various l10n
repositories commits/hashes is going away soon.

-- 
Thanks,
Maxim