Hi Jonas, 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)? Paul
OpenPGP_signature
Description: OpenPGP digital signature
