musescore 2.0.3+dfsg-1

[Peter Jonas]

Hi again,

I concede that the policy line "explicitly intended to be used in this
way" does appear to refer to the library rather than the package
linking to it. I'm still not convinced that this usage counts as a
convenience copy, which the policy suggests is a copy included merely
to save users the trouble of installing the library themselves, but I
do see the value in using (and if necessary fixing) the system
Freetype for everyone. However, I fear that the practical result of
this will be to make the experience for MuseScore's users on Debian
inferior to the experience of users on other platforms. I can only
hope that any issues which do arise as a result of this are addressed
with the same enthusiasm as this discussion.

Best,
Peter

On 16 July 2016 at 16:23, Fabian Greffrath <fabian at debian.org> wrote:
> Hi Peter,
>
> Am Freitag, den 15.07.2016, 14:16 +0100 schrieb Peter Jonas:
>> the policy itself. This policy explicitly allows bundling when a
>> package is "explicitly intended to be used in this way." MuseScore is
>
> I am sorry but I believe that Jonas is right and you misunderstood this
> part of Policy. It reads "Debian packages should not make use of these
> convenience copies unless the included package is explicitly intended
> to be used in this way". In this case *the included package* is
> freetype and it is definitely not intended to be used this way. Policy
> is rather explicit on how to further proceed in this case:
>
> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
>
> So, what libraries could probably be intended to be used this way? I
> think there are only very few exception, for example speed-optimized
> math libraries with hand-crafted ASM code that would suffer from
> register shortage on certain architecture of compiled as PIC (e.g.
> djbfft); or maybe header-only libraries that only consist of static
> inline functions and macros (though I currently have no example for
> these at hand).
>
>> not likely to be a priority for the developers of Freetype. MuseScore
>> needs to know the exact size and position of every symbol on the page
>> to be able to lay them out efficiently without causing collisions. In
>> an ordinary text document slight differences in kerning between
>> operating systems might cause a word to be moved onto the next line,
>
> It seems to me what Musescore is actually looking for is an entire
> static font rendering stack. Please note that freetype is only a part
> (though a very important) of the whole font rendering stack. There are
> plenty other libraries involved that could modify the result of fonts
> being rendered on screen, e.g. harfbuzz, fontconfig and pango/cairo. I
> am sure you are not going to include known-working copies of these as
> well.
>
> Also:
>
> $ zgrep CVE /usr/share/doc/libfreetype6/changelog.Debian.gz  | wc -l
> 53
>
> So, no, please don't do that!
>
>  - Fabian