On Wed, 3 Apr 2019 00:04:43 +0200 Andreas Beckmann <a...@debian.org> wrote: > [...] > > 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 > >
Hi, >From a release team PoV, we would very much like to see this be fixed with a Breaks as well. > Hi Pirate, > > On Sat, Oct 20, 2018 at 10:39 AM Pirate Praveen > <prav...@onenetbeyond.org> wrote: >> On Mon, 15 Oct 2018 16:26:23 +0300 Adrian Bunk <b...@debian.org> wrote: >> > When it has been observed that ending up with both libprotobuf10 and >> > libprotobuf17 in a binary will not work, then this should be expressed >> > through the package dependencies. > ... of the binaries that need to be compiled with the same ProtoBuf version. > >> Are you planning to upload this fix? Testing migration is currently >> blocked by this rc bug and there is a delay caused by autopkgtest failure. > Let's break it to parts. > 1) Can libprotobuf10 and libprotobuf17 installed together and > independent packages working correctly with these libraries? Yes, > these are possible. I don't see the need to break the old > libprotobuf10 package. > While libprotobuf10 and libprotobuf17 *can* be installed together, nothing in buster should rely on libprotobuf10 any longer. Indeed, libprotobuf10 is not even in buster any longer. > [...] >> > That would avoid a couple of potential problems in situations like >> > stretch->buster upgrades or for testing users. > Breaking libprotobuf10 would cause more problems. All ProtoBuf > related packages would need to migrate once and together. Cause > problem with any local compiled program for libprotobuf10. > This may have been an issue at that time, but it no longer is (as libprotobuf10 is not in testing anymore). On the flip side, having libprotobuf10 remain on some systems during upgrades will spell trouble for us later. Each release, we see a number of upgrade issues related to old, long obsolete packages that were removed releases ago. Lets ensure libprotobuf10 does not become one of them for bullseye or later. Thanks, ~Niels
