multiarch environment makes testing of new package version for developers very awkward
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg (Ubuntu) |
Won't Fix
|
Critical
|
Unassigned |
Bug Description
In the new multiarch environment there is both the amd64 and the i386 version of each multiarch library installed. The two versions of the libreary have to be from exactly the same package build from buildds which is checked by whether the files in /usr/share/
If I do development work for Ubuntu, modifying a source package bumping the version number, and then building and installing this package on my system so that I can test it before uploading, the install fails in the configure part with
dpkg: error processing libcups2 (--install):
libcups2:amd64 1.5.0-4 cannot be configured because libcups2:i386 is in a different version (1.5.0-3)
dpkg: error processing libcups2:i386 (--install):
libcups2:i386 1.5.0-3 cannot be configured because libcups2:amd64 is in a different version (1.5.0-4)
The only way to get my new package installed is to remove the i386 library with --force-depends:
sudo dpkg -P --force-depends libcups2:i386
Then I can install and test my new package version but my system is inconsistent, preventing me from being able to use apt-get to update the system or to install other packages.
Changed in ubuntu: | |
importance: | Undecided → Critical |
milestone: | none → ubuntu-11.10-beta-1 |
affects: | ubuntu → dpkg (Ubuntu) |
Changed in dpkg (Ubuntu): | |
milestone: | ubuntu-11.10-beta-1 → none |
milestone: | none → ubuntu-11.10-beta-1 |
I'm sorry, but the issue you describe here is a consequence of a fundamental design requirement of multiarch; this is not something that's going to be changed.
> The two versions of the libreary have to be from exactly the same package doc/<package> / are identical.
> build from buildds which is checked by whether the files in
> /usr/share/
This is not about checking the file contents at all, it's about the fact that all architectures of a package must be at the same version in order to be configured. Yes, this means more work to do test builds of a package if you are going to do your test installing on a system that has foreign-arch copies of the library installed. The only thing I can suggest is to do your package testing in a clean environment to avoid this - one without flashplugin or skype installed (the only two applications that use multiarch currently).