El 10/11/11 12:34, Jakub Wilk escribió:
* Santiago Vila <sanv...@unex.es>, 2011-11-03, 18:38:
With the advent of multi-arch, such behavior has become a problem. If
a package is marked as "Multi-Arch: same" all the files (including
*.mo) have to be identical across all architectures.
Hmm, why do they have to be identical?
It is not enough that both types of systems (big and little endian)
are able to read and use both types of .mo files, as it seems to be
the case?
If .mo files are useable everywhere, regardless of their endianess, I
would say that the multi-arch requirement is not reasonable.
"Multi-Arch: same" makes it possible for users to install a package for
more than one architecture at the same time. If files with same name are
not identical across architectures, package manager has to resolve the
conflict somehow, and it does it by simply aborting the installation,
e.g. like that:
| # apt-get install -qq libavahi-common-data:powerpc
| (Reading database ... 59644 files and directories currently installed.)
| Unpacking libavahi-common-data:powerpc (from
.../libavahi-common-data_0.6.30-5_powerpc.deb) ...
| dpkg: error processing
/var/cache/apt/archives/libavahi-common-data_0.6.30-5_powerpc.deb
(--unpack):
| './usr/share/locale/he/LC_MESSAGES/avahi.mo' is different from the
same file on the system
| configured to not write apport reports
| dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
| Errors were encountered while processing:
| /var/cache/apt/archives/libavahi-common-data_0.6.30-5_powerpc.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
Does it make things clear?
Yes, I now see what the problem is, but I don't see that making every
.mo file to be always little endian again is the best solution. We could
also tell dpkg somehow that different files in /usr/share/locale are ok
in this case.
Note that the problem would affect only tiny minority of packages:
"Multi-Arch: same" is useful mainly for shared libraries and they rarely
come with translations.
In such case, making those packages to depend on another "Arch: all"
package containing just the translations would solve the issue, would it
not?
(For the record, I happen to maintain a library containing translations,
and I have always seen it as an "anomaly", this would force me to do
what I feel is the "right thing").
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
