Comment 7 for bug 1564778

Hello and thank you for this update!

If I understand this correctly, the issue is when coming from Trusty, a file is now owned by two packages.

A user would obviously experience this on Xenial during upgrade when the new version of libsane-common gets installed.

But then they might also experience it on Y & Z if they choose to resolve the issue on X by removing libsane-common on X, and release-upgrade'ing instead, and then trying to install libsane-common again on the new release and it fails agin. Except that libsane depends on libsane-common, so I believe it would also be removed in that case. So, IIUC, this cannot actually happen on Y or Z. You only need to modify those versions so that they are after X for upgrade purposes from X?

Your fix is to ensure that (old) versions of libsane are removed so the file conflict doesn't occur, is that correct? (note that all of these questions will be necessary to satisfy https://wiki.ubuntu.com/StableReleaseUpdates.)

Finally, I believe your X and Y versioning is a bit off. I tend to use https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging as my standard, and that would result in:

Z: 1.0.25+git20150528-1ubuntu3
Y: 1.0.25+git20150528-1ubuntu2.16.10.1
X: 1.0.25+git20150528-1ubuntu2.16.04.1

While your version is not incorrect, it assumes that release naming will proceed forever alphabetically sorted forwards, which we (presumably) know is not going to happen post-Z, so it's a good habit to break.

I am going to ask the -devel list about this, as I'm not sure what the right way forward is (it feels weird to add to our delta just to allow for the fixlet).

Thanks!
-Nish

P.S. In case you're interested, it seems like sane-backends could do with a fresh merge to Debian unstable (last done in Wily!)