Quoting Paul Gevers (2021-02-07 22:04:25) > 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.
I know that you are wearing your Release Team member hat. I appreciate your looking into this issue - with or without that hat on. I agree with your reasoning that changing 20 packages isn't great and that alternative options are more relevant. I only dismissed the question - i.e. last half of your last sentence: "how bad would instead getting fonts-urw-base35 be for those that rely on additional features of gsfonts?" I am sorry if I misunderstood that question. If I _did_ understand it then I don't know how to sensibly answer it, because those that rely on additional features of gsfonts _already_ do not (reliably) use gsfonts. > > 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. I thought you did, but got uncertain due to that question of yours. Again, I am sorry if I missed the meaning of that question :-( > > 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. Right, when a) is implemented, this bug can be solved because then this package should no longer be used by any packages. NB! I have *not* closely examined each case e.g. for versioned dependencies, but I guess even that should be possible nowadays to address without messing directly with those packages, using versioned Provides. > > 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? I have done no preparations for this option - I don't like this option. It's just part of my answering my own question - to clarify why as I see it the only sensible approach here does _not_ involve directy messing with 20+ packages. > > 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*? I think that this namespace clash is a real issue, regardless of it having existed a long time. If the only options available to solve this issue involved messing directly with 20+ packages, then (if I had a Release Team member hat) I would probably judge it too late and flag it as ignore-for-this-release. > > 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? Yes! Arrgh, sorry for that crucial and confusing mistake. > > ...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. That's your call to make. > > 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? No, I don't know - I just assumed that the owner of a package gets emails posted to a bug (but I have been wrong before about how our bugtracker works...). Added now explicitly. - 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
