Re: What is the correct fix for this piuparts related issue?
Hi Thomas,
On 13.07.2014 10:41, Thomas Moulard wrote:
I recently uploaded a binary incompatible new version of the ViSP C++ library.
We have in testing a package libvisp2.8_2.8.0-5.1 and in unstable a
package libvisp2.9_2.9.0-2
So far, so good. The library changed it's SOVERSION and thus a new
binary package is necessary.
piuparts testing2sid check now fails, see:
https://piuparts.debian.org/testing2sid/fail/libvisp-dev_2.9.0-2.log
Preparing to unpack .../libvisp2.9_2.9.0-2_amd64.deb ...
Unpacking libvisp2.9:amd64 (2.9.0-2) ...
dpkg: error processing archive
/var/cache/apt/archives/libvisp2.9_2.9.0-2_amd64.deb (--unpack):
trying to overwrite
'/usr/share/visp/data/wireframe-simulator/circles2.bnd', which is also
in package libvisp2.8:amd64 2.8.0-5.1
Why are the files under /usr/share/visp part of the library?
How are they used?
This is forbidden by policy [1] for precisely this reason:
"If your package contains files whose names do not change with each
change in the library shared object version, you must not put them in
the shared library package. Otherwise, several versions of the shared
library cannot be installed at the same time without filename clashes,
making upgrades and transitions unnecessarily difficult."
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Preparing to unpack .../multiarch-support_2.19-5_amd64.deb ...
Unpacking multiarch-support (2.19-5) over (2.19-4) ...
Errors were encountered while processing:
/var/cache/apt/archives/libvisp2.9_2.9.0-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
2m29.1s ERROR: Command failed (status=100): ['chroot',
'/srv/piuparts.debian.org/tmp/tmpk7TUWx', 'apt-get', '-yf',
'dist-upgrade']
Apparently, libvisp2.8 and libvisp2.9 provides the same file which is
obviously an issue if one tries to install the two packages side by
side.
In this particular case, should libvisp2.9 declare a break+replace on libvisp2.8
or is there another better solution to solve this issue?
The correct solution (assuming both 2.8 and 2.9 can use the same files)
is to but all /usr/share/visp files into another (Architecture: all)
package, e.g. visp-common.
If the files are incompatible between library versions, they should be
in /usr/share/visp-X.Y.
Best regards,
Andreas
1:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files
Reply to: