Hi Jonas, On 07-02-2021 13:44, Jonas Smedegaard wrote: > Quoting Paul Gevers (2021-02-07 12:07:08) >> 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:
? I'm wearing my Release Team member hat here. Fixing > 20 packages
isn't great at this stage of the release. So, *if* this bug is indeed so
severe as you claim, them I'm looking for options. Adding the Provides
to fonts-urw-base35 enables us to remove gsfonts, which is what you
want. I now realize I didn't make that totally clear and I think you
misread my intentions.
> 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.
I understood that from your earlier mail, thanks.
> 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.
Ack.
> 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"
This is what I had in mind. You forgot to add, and drop gsfonts the binary.
> 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)
In my opinion, too late. And again, are the bug reports for those
packages already there?
> 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.
But you claim that this is RC worthy. What's more, you claim that very
late in the release cycle (I think the issue hasn't changed since
buster, jessie or even longer) when there is not much time to decide
what to do and gsfonts is *currently* a key package that can't just be
removed so we need to decide the path to continue, autoremoval won't do
the work for you. Is this font issue really worth all that *now*?
> 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.
^^ I assume you meant a) here. So I think we agree?
> ...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?
That's exactly my question too. And I'm really leaning now to "not for
bullseye, it's too late". This is no regression from the last couple of
releases after all.
> 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).
So, is the maintainer in the loop? He replied once, but do you know if
he follows our conversation?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
