On 2016-06-30 08:09, Chris Leishman wrote:
> Hi Andreas,
>
> If you don't mind, I was hoping for a little direction in resolving this.
Let's discuss this within the bug report ... even if it does not fit
perfectly.
> It seems I've got a mistake in the packaging, whereby the -dev package for
> the library contains the soname - i.e. libneo4j-client8-dev. I did this
> because it contains the symlink
> ./usr/lib/x86_64-linux-gnu/libneo4j-client.so -> libneo4j-client.so.8.0.0.
>
> But I believe that was a mistake, and the package should simply be
> libneo4j-client-dev.
That's the reasonable approach (unless you have good reasons to need two
versions of the -dev package, but then you usually need two source
packages, too).
> What's the best way to remove both libneo4j-client7-dev and
> libneo4j-client8-dev, and replace with a package libneo4j-client-dev? I can
Are there any packages with Build-Depends: libneo4j-client[78]-dev?
Do they have versioned dependencies?
Or do all use the virtual package libneo4j-client-dev?
> upload a new package with the new name, but I'm unclear how to force
> removal of the others from the distribution. Will using 'Provides' +
> 'Conflicts' + 'Replaces', as per policy 7.6.2, achieve this? Do I make it
> '(Provides|Conflicts|Replaces): libneo4j-client7-dev libneo4j-client8-dev`?
We currently have:
Package: libneo4j-client7-dev
Source: libneo4j-client
Version: 0.9.2-1
Provides: libneo4j-client-dev
Depends: libneo4j-client7 (= 0.9.2-1)
Package: libneo4j-client8-dev
Source: libneo4j-client
Version: 1.0.0-1
Provides: libneo4j-client-dev
Depends: libneo4j-client8 (= 1.0.0-1)
If you introduce
Package: libneo4j-client-dev
Depends: libneo4j-client8 (= ${binary:Version})
Breaks: libneo4j-client7-dev, libneo4j-client8-dev
Replaces: libneo4j-client7-dev, libneo4j-client8-dev
Provides: libneo4j-client7-dev, libneo4j-client8-dev
that should work quite well. You only need the Provides if there are any
reverse depends/build-depends on the versioned package name.
Breaks+Replaces can be unversioned in this case. Or use a version
constraint of (<< 1.0.0-2~) (assuming the new package will be uploaded
in rev -2).
The old -dev packages will be no longer installable since they have a
strict dependency on the library package, so they will get removed
automatically on upgrades. There won't be an automatic upgrade path that
installs the unversioned -dev package if the versioned -dev package was
installed, but that is probably no needed (v7 was never in stable, only
in testing, v8 won't go to testing).
Andreas
