[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Towards multi-arch: "Multi-Arch: same" file conflicts



On Fri, 18 Nov 2011 23:39:20 -0600
Peter Samuelson <peter@p12n.org> wrote:

> 
> [Jakub Wilk]
> > The most common reasons for cross-architecture differences appear to
> > be (in random order):
> 
> > - Compiling GNU message catalogs with gettext, which uses native
> > endianness (see bug #468209).

(Hmm, I did get v.carried away earlier in this bug report didn't I?
Sorry, Santiago. I genuinely thought this was a lot more important at
the time. All that cross-building was driving me scatty.)
 
> Having read that bug log, it's not clear to me whether there's a
> consensus about what to do about these.  Neil thinks we need native
> endian .mo (which is problematic for multiarch)

Native isn't quite the right meaning - same endianness as the
DEB_HOST_ARCH platform is what I intended to implement in Emdebian
based on the --endianness option to msgfmt. (Native could mean
DEB_BUILD_ARCH which is worse for cross-building than just picking one
endianness and sticking with it.)

>, others think we need
> .mo to be Arch: all and "dont-care"-endian.  Has any consensus emerged?

After more work on exactly what's going on with endianness and .mo
files, Emdebian switched to making our TDebs Arch:all and letting
gettext deal with the endianness before the Squeeze release, by which
time the cross-built version of Emdebian was already inoperable. I
should have followed that up to the bug log - it was closed and
archived at that point but I forgot to check it. Sorry.

http://www.emdebian.org/emdebian/tdebs.html

As long as the behaviour is always *consistent* across native builds and
cross-builds, I would be happy with having all .mo files with the same
endianness. By preference, little endian.

Like Santiago (468209#66), I maintain a library which has translations.
For that package I have put the .mo files into a -data package
(qof-data) precisely because that allows the Architecture:any libqof2
to depend on the Arch:all qof-data, thereby solving the MultiArch
problem.

This is also compatible with the TDeb proposal for Arch:all TDebs which
contain .mo files (as well as the more difficult problem of the
translated debconf templates file) because packages like qof-data can
easily be processed as TDebs once those mechanisms are available. 

> And is it worth splitting out a -l10n or -data package from a library
> just so the library itself can be M-A: same?  (I suppose a side benefit
> is you can use Recommends and cut down a little on the size of your
> strict Dependency closure.)

Yes, it is worth having -l10n, -tdeb, -data packages, precisely to get
the library M-A: same. MultiArch wasn't a consideration when #468209
was opened or when the TDeb proposal was created in 2008.

There are other reasons to split out the .mo files:

1. Updates to translations should not require source NMU's.

2. Translation data should not be distributed in architecture-dependent
packages. 

3. Translators should have a common interface for getting updates into
Debian (possibly with automated TDeb generation after i18n team review).

However, the TDeb proposal for Debian is stalled due to disagreement
with the dpkg maintainers over the implementation mechanism. I want to
see the arrival of a Multiarch-aware dpkg in unstable before raising
that discussion again.

In the meantime, I'm happy for all libraries packaging translations to
add -l10n, -tdeb, -data or -common Arch:all packages in order to meet
the higher priority of implementing MultiArch. Indirectly, this would
help the eventual implementation of TDebs.

If there's to be a release goal for that, I'm happy to help with it.

Santiago wrote:
> 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").

I agree with this completely and, as above, have fixed the anomaly that
way for one library which uses gettext translations.

There remains some disagreement:

Santiago wrote:
> 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.

Having at first put a lot of time into generating .mo files which have
matching endianness to the DEB_HOST_ARCH, I have changed my mind on
exactly how this should work. Emdebian has tried .mo files which differ
between architectures and it isn't worth the effort. Santiago was right
the first time, I was wrong: let gettext deal with the load at runtime
and don't fuss about the endianness of the file in /usr/share.
*However*, I think that this means that we *should* make every .mo file
to always be little endian.

I'm sorry if this seems like an about turn but what I originally wanted
from #468209 was merely the documentation of the option so that
Emdebian could use it outside of Debian builds to deterministically set
the endianness and do the tests. If that had meant changing stuff in
Debian, I was happy to do that. Things turned out differently.

I did not intend #468209 to cause a change in Debian behaviour by
implementing or not implementing a change in how gettext operated. From
reading the log, I don't see where any change of gettext behaviour
within Debian was mentioned as being implemented in gettext itself. It
was all about whether the --endianness option should be documented and
how it could be used *outside* Debian in the cross-built version of
Emdebian which itself is to be completely redesigned once MultiArch is
in place.

(Nothing here affects the binary-compatible "Grip" version of Emdebian
which I'm currently working on integrating into Debian and which
already uses Arch:all TDebs.)

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpcQOMMNec8K.pgp
Description: PGP signature


Reply to: