Resolve file conflict with Breaks/Conflicts.

[dobey]

This adds a Breaks/Conflicts on libunity-api0 for libunity-api1 to resolve
the installability issue when upgrading a system which already ahs the former
installed, due to the ABI break being released without the package name being
fixed to match. Also change the URL to the GitHub URL.

Fixes #20 and ubports/crossbuilder#27

[RAOF]

Isn't the right fix here to fix the SONAME of the library so that it matches the package name? Then libunity-api1 wouldn't conflict with libunity-api0.

If there's actually been an ABI break then replacing libunity-api0 with libunity-api1 is likely to result in things crashing.

[dobey]

Isn't the right fix here to fix the SONAME of the library so that it matches the package name? Then libunity-api1 wouldn't conflict with libunity-api0.

The problem is the SONAME was changed before the package name. The package name is correct now, which is why the conflict exists. The conflict exists, because both packages have .so.1 in them.

[RAOF]

Aha!

In that case you want Breaks: libunity-api0, Replaces: libunity-api0; Ideally you'd have Breaks: libunity-api0 (> $VERSION_THAT_BROKE) so you can keep the old one installed if necessary.

Breaks+Conflicts doesn't make sense; Conflicts is a strictly stronger restriction that Breaks.

[dobey]

Breaks+Conflicts doesn't make sense; Conflicts is a strictly stronger restriction that Breaks.

Ah, right. So what I want is Conflicts+Replaces instead. I guess I recalled the combination slightly wrong.

Ideally you'd have Breaks: libunity-api0 (> $VERSION_THAT_BROKE) so you can keep the old one installed if necessary.

Ideally this wouldn't have been broken in the first place, but looking through the past commits, I'm unable to find when it was actually broken and made it into the UBports repo. But everything should already be rebuilt against the newer version, so simply forcing the old one out should be fine at this point.

[UniversalSuperBox]

I see now! So, by rebuilding any packages that build-depend on libunity-api-dev, they will automatically get the new unity-api1 package as their dependency. The issue was always one step up, as it were. In this case, I needed to rebuild thumbnailer.

This is still a good fix, since I was not allowed to install the build-deps package instead of ending up with an inconsistent state.

If this looks correct, @RAOF, let's merge it.

[dobey]

(Please Squash and merge if someone other than I merges this)