On Sun, Apr 11, 2021 at 08:02:20PM +0200, Ivo De Decker wrote: > There is a theoretical and a practical aspect to this issue. From a > theoretical point of view, the dependency relations should not be stricter > than necessary, to allow partial upgrades and to avoid complicating > migration to testing of library transitions.
Then again, I believe the project at large is moving towards stricter-than-necessary dependencies (see the implied dh_makeshlibs -V in dh compat 12, lintian nagging about the Build-Depends-Package in .symbols files, etc). I also don't believe a stricter dependency between libpoppler102 and libpoppler-glib8 would have any of the issue you mention. > It would create the desired dependency, but I'm not sure if this is better > than just manually adding it to the 2 remaining packages we are aware of > (especially at this stage of the freeze). > For now, though (and especially for bullseye), I think we should accept > that we aren't going to solve this issue in general. The best we can do, is > to try to fix obvious cases where we are aware of the issue. In other cases, > we'll probably need to advise our users to do a full upgrade instead of a > partial one. So, if that's what you think, should I upload an inkscape with a manual dependency on libpoppler-glib8 >= 20.09.0? (mhh, is there a way to do this without writing it in d/control?). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature