[Pkg-fonts-devel] Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

Paul Wise pabs at debian.org
Sun Jan 22 01:40:17 UTC 2017

On Sat, 2017-01-21 at 12:39 +0100, Fabian Greffrath wrote:

> I find this by far the most convincing argument, although I still find
> it difficult to accept that it should make a difference for Debian as a
> mere downstream distributor. We provide many packages with fonts in OTF
> format and while this is accepted as a proper source for some, it is not
> for others because of upstream design decisions?

Upstream decisions are the best proxy we have for preferred form for
modification, since they are the ones who are working on the project.

Lets take the example of the obfuscated Xorg nv driver. NVIDIA had some
released driver code, but they were not developing that code. Instead
they had some secret internal code that they developed. Their release
process was to automatically obfuscate the code by expanding macros and
replacing constants with numeric values and other things. Clearly their
preferred form for modification was that internal code and not the
released code. This was a DFSG violation because upstream and Debian
users did not have equivalent access to the work.

Another example is Perl. Perl has a Configure script that the Debian
Perl Team has declared is source. Helmut Grohne found a bug in that
script that prevented it from working in cross-compilation scenarios.
He attempted to send a patch for it upstream but discovered that it was
in fact generated from another file (so wasn't source despite what the
Debian Perl team said) and the issue was already fixed in the other
file but the Configure script hadn't been built from source in ages and
it couldn't be built any more. This highlights that we need to be
always (re-)building from source in order to detect FTBFS and to prove
to our users that they have the freedom to modify and rebuild Debian.

Both of these are slightly different to Firacode, which is the fair bit
more straight forward issue of non-free Build-Depends. Based solely on
the commits in their github repo, the source for Firacode is the
.glyphs file and not the TTF/etc files. To convert that to the other
formats, you currently need the proprietary Glyphsapp. According to
Debian Policy, that means the font belongs in contrib because we can't
guarantee to our users that they will be able to modify the source and
rebuild the font using only packages in Debian main. Upstream and
Debian main users do not have equivalent access to the work.

> Well, RMS himself told me that the Type1 format in which the fonts are
> distributed is considered a proper source format. Apparently he doesn't
> even care about what tools upstream used to create the fonts as long as
> they are distributed in a proper source format.

The point I've been trying to make so far is that what the proper
source format is, is completely dependent on the development scenario.
It can be the source format or it can not be the source format,
depending on the development processes upstream chose for the fonts.

Quite unrelated to that is whether or not it is a good choice of source
format or not. As a software developer used to version control I find
binary formats a poor choice but upstream might have really great font
tools that deal fine with binary fonts by doing visual comparisons.

> Agreed, but I don't think that this (i.e. "is it easy or even possible
> to create a patch that upstream would outright accept in that form?")
> should be a criterion to decide if a package is suitable for Debian
> main or not (as long as it is possible to create the patch in the first
> place, that is).

Ack, I wasn't suggesting that. I was suggesting that this is the best
way to determine which files in the upstream repository are source and
which are not source. Doing that would really be forcing the issue
though. You really don't need to go that far, for Firacode you just
need to look at the commits in the repository to determine that.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20170122/e9550c7d/attachment.sig>

More information about the Pkg-fonts-devel mailing list