[Pkg-gtkpod-devel] Bug#620065: fixed in libimobiledevice 1.1.0-3

[Raphael Hertzog]

Hi,

First of all, I wanted to suggest to drop the Conflicts and just keep the
Replaces. The Replaces is enough, the only problem is that the FDI file
will be lost if libimobiledevice2 is removed while some application
still use libimobiledevice1 (the other cases are correctly handled by dpkg
whatever the order of installation of the packages).

It's really not a big problem and much less problematic than the
non-coinstallability of both libraries. And as I understand it's
temporary anyway.

On Mon, 18 Apr 2011, Julien BLACHE wrote:
> The multiarch requirements aren't relevant here, as the file is
> installed in /etc and is identical regardless of the architecture the
> package is built for. So the overlap will be handled by dpkg. That is,
> if the wiki page is accurate.

The file is in /usr/share not /etc, but you're right, dpkg will cope with
it.

> > Well, we can't bin-nmu in experimental so it means fake source upload in
> > experimental with increased build-dep just to be able to provide updated
> > binaries of all packages using libimobiledevice1...
> 
> Those uploads will be needed anyway, as I think libimobiledevice2
> is/will not be API-compatible with libimobiledevice1. So, could be a
> moot point.

Julien (Lavergne), do you know if this is the case?

If yes, can you arrange with the reverse build-dependencies to prepare the
transition in experimental?

On Mon, 18 Apr 2011, Mehdi Dogguy wrote:
> On 04/18/2011 07:18 PM, Raphael Hertzog wrote:
> >
> >Well, we can't bin-nmu in experimental
> 
> oh. yes, we can.

I know we can but the bin-nmus won't use the updated libimobiledevice-dev
from experimental unless the build-dependencies are updated to require it.
Thus a bin-nmu is not enough.

On Mon, 18 Apr 2011, Julien Lavergne wrote:
> Another argument against this solution was the need for the package to
> go twice in NEW (1 with the creation of the -common binary, 1 when it
> will be dropped with HAL support), x2 because there are 2 different
> versions in unstable and experimental.

OK, then please just keep the Replaces and drop the Conflicts. It will do
the right thing for all people except those who might downgrade apps using
libimobiledevice from versions using libimobiledevice2 to versions using
libimobiledevice1.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)