[Pkg-samba-maint] [Pkg-giraffe-maintainers] Bug#857377: kopano-dev: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/x86_64-linux-gnu/libmapi.so

[Guido Günther]

Hi Carsten,

I'm cc'ing the openchange maintainers so the become now that we
have conflicting libs in Debian atm.

On Fri, Mar 10, 2017 at 07:50:33PM +0100, Carsten Schoenert wrote:
> Am 10.03.2017 um 17:52 schrieb Andreas Beckmann:
> > Hi,
> > 
> > during a test with piuparts I noticed your package fails to upgrade from
> > 'jessie'.
> > It installed fine in 'jessie', then the upgrade to 'sid' fails
> > because it tries to overwrite other packages files without declaring a
> > Breaks+Replaces relation.
> ...
> >   Selecting previously unselected package kopano-dev.
> >   Preparing to unpack .../kopano-dev_8.1.0-3_amd64.deb ...
> >   Unpacking kopano-dev (8.1.0-3) ...
> >   dpkg: error processing archive /var/cache/apt/archives/kopano-dev_8.1.0-3_amd64.deb (--unpack):
> >    trying to overwrite '/usr/lib/x86_64-linux-gnu/libmapi.so', which is also in package libmapi-dev 1:2.2-5+b1
> 
> looks like we have some clashing libaries now.
> libmapi-dev comes from the openchange package.
> 
> https://tracker.debian.org/pkg/openchange
> 
> I think this needs some other name for the library that comes with
> kopanocore. That's one thing Guido was mentioning in the past and making
> libraries private libraries for Kopano. That's no Debian specific
> problem in the end, this issue the users of the official Kopano packages
> can also run into on Debian based systems.

The library needs to be renamed or made private. Since we expect other
tools to use it the former would be a better option. Marc, can you
discuss the name change at kopano? On the other hand it seems that
openchange is neither in stretch nor in sid so iff openchange is not
developed anymore we could keep the name and just add a conflict. Maybe
one of the openchange maintainers can shed some light on this?

Cheers,
 -- Guido