Quoting Paul Gevers (2021-02-07 12:07:08) > On 07-02-2021 11:05, Jonas Smedegaard wrote: > >> And what are the consequences of that? Please assume I have no clue > >> how fontconfig works at all. > > [...] (elaborate explanation, thanks) > > >>> Feel free to lower severity or repurpose as a wishlist request to > >>> document what is notable about this font over fonts-urw-base35, or > >>> whatever - I have no strong attachment to this issue, it can > >>> linger for another 10 years without me noticing much... > >> > >> Your comment suggest that we should ignore this issue for bullseye. > >> There's quite some work to get it removed, it's late in the release > >> cycle. > > > > That remark was made as a reply to the maintainer of > > fonts-urw-base35 who argued that non-documented secondary features > > of gsfonts should be treated as primary for that package. > > > > If we want to permit fonts to evolve while staying true to their > > stated primary purpose, then it is my understanding that it is > > doable by simply a) having fonts-urw-base35 provide/break/replace > > gsfonts, and then drop gsfonts. > > > > It is my understanding that it is only "quite some work" if we want > > to honor whatever shape a font has at some release. I.e. the > > equivalent of honoring "...but my code _needs_ libssl 1.0, > > regardless if that breaks all libssl 1.1 uses". > > With "quite some work" I mean that there are > 20 packages in testing > that need to change (are bugs already filed?). I understand from your > explanation that we already have a "Provides" in the fontconfig ID, > how bad would it be if fonts-urw-base35 add the Debian Provides: > gsfonts too? If that happens, we can (technically at least) drop > gsfonts, but how bad would that look (for those that rely on the > additional features of gsfonts)?
I think you are asking the wrong question here:
Those that rely on the undocumented additional features of gsfonts
already today cannot be certain that they have them! Most systems have
ghostscript installed and therefore not *only* gsfonts but *both* that
and fonts-urw-base35.
For its documented purpose, gsfonts is *known* to be slightly broken -
and using fonts-urw-base35 is the solution to that bug. But as long as
gsfonts is *also* installed, each and every user must *bypass*
fontconfig and explicitly use file paths to ensure that they get the
non-broken fonts.
Instead, I would ask which of these is more work:
a) ensure that 20+ packages declaring a dependency on "look-alike fonts
of the Adobe PostScript fonts" get the most accurate look-alike for
the Adobe PostScript fonts: Have the package fonts-urw-base35
declare "Provides: gsfonts"
b) ensure that 20+ packages declaring a dependency on "look-alike fonts
of the Adobe PostScript fonts" get a specific (known inaccurate!)
look-alike for the Adobe PostScript fonts: Have each of those
packages declare "Conflicts: fonts-urw-base35" (unless they do *not*
use fontconfig but explicit file paths to load those fonts)
c) ensure that 20+ packages declaring a dependency on "look-alike fonts
of the Adobe PostScript fonts" continue to only maybe get what they
declared - depending on whether their system happens to provide them
different fonts instead.
My own answer would be that b) is the most work, c) is the least work,
but b) is reasonably little work while solving this bug.
...which gets us back to the original question of filing this bugreport:
Is this bug real, and if so is it worth fixing for bullseye?
Answering that question involves the maintainer of fonts-urw-base35, who
seems to agree that the issue is real, but seems to consider c) more
reasonably to preserve than to fix this bug (hence my comment that I can
choose to ignore this bug for 10 more years if need be).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
