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

[Maxim Cournoyer]

Hello,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> 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).
>
> The '%upstream-linux-source' procedure was not easily avoidable, and
> it's not at all convenient to use because it requires passing in the
> nix-formatted hash.
>
> In contrast, the argument for adding 'unstream-firefox-source' as a
> toplevel binding is a very slender thread, and it would immediately
> enable users to type commands like:
>
>   guix build -e '(@@ (gnu packages gnuzilla) upstream-firefox-source)'

> At which point Guix would dutifully provide non-FSDG-compliant software
> to the user.
>
> Moreover, in another of your proposed commits ("gnu: Add a
> 'update-mozilla-locales' helper for maintenance"), in a comment, you
> literally steer the user to download the Firefox source and provide the
> precise command to do it.
>
> This is a slippery slope.  It is not the role of core Guix to facilitate
> downloading Firefox source code for purposes of IceCat development.
> That is the domain of the IceCat project itself.

We're already on a slippery slope for fetching the non-free source
ourselves to process them, but I'd argue that this doesn't steer users
toward non-free software, but rather empowers them to free the original
source of the software they use.

In an ideal GNU FSDG world put forward by some proponents, we'd not even
let users' machine fetch the non-free source and instead host it
somewhere else, ready to be used.

> I feel very strongly about this.

I don't really see how "obsfuscating" the non-free source we process
makes it much different, or how having an easier access to that non-free
source from the CLI would steer users toward "using" non-free software.
A source is not a usable (executable) form.

But anyway, with that opinion of mine expressed, I've reverted the
offending bits so that we can move on, knowing that once we get the
strings_all.tar.zst locales data planned in future releases, it won't
matter much anyway.

See the result in v4.

-- 
Thanks,
Maxim