Hi Mark, Mark H Weaver <m...@netris.org> writes:
> Hi Maxim, > > Maxim Cournoyer <maxim.courno...@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
