On Sun, 31 Mar 2019 16:51:51 +0200 Giovanni Mascellani <g...@debian.org> wrote: > Hi, > > On Sat, 27 Oct 2018 17:30:32 +0300 Adrian Bunk <b...@debian.org> wrote: > > Properly handling this in package like libarcus3 becomes difficult once > > you consider that such packages might be backported to stretch-backports > > and would use libprotobuf10 there. > > > > We might even end up with upgrade failures if a user could end up with > > a nonworking combination of packages installed during an upgrade, and > > a maintainer script calls such a nonworking program. > > This is a sensible concern, but I share László's view here: the two > versions of protobuf are not in conflict and can happily coexist on the > same system, so there is no reason to declare a Break. What must be > ensured is that no package depends on both at the same time: wouldn't it > be better that this last package declared Conflicts and possibly > Build-Conflicts towards the version of protobuf that is not meant to be > used?
What's the point in having a cruft package (libprotobuf10) installable in buster, if it has been shown that this allows partial upgrades (yes, partial upgrades *are* supported) that reproducibly cause failures? The cruft package itself does not cause harm. It's the combination with other packages that's problematic. There is an easy solution to prevent all these (see Subject), without imposing any limitation on buster. While it is possible to add the Breaks to libarcus3 instead, is this sufficient to prevent *all* failure cases? Which package will be the next to be touched to prevent mixture errors? There is no point in touching Build-Depends, as we can't build against this cruft in sid. Andreas
