On Fri, 29 Feb 2008 11:51:19 +0100 (CET) Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Feb 2008, Neil Williams wrote:
>
> > .mo files *are* architecture dependent and should be handled as such.
> > Just because 'it happens to work' right now does not mean it is the
> > correct way to handle .mo files.
>
> I'm curious: Do you plan to do the same with PCM .wav files?
Not for Emdebian - we are unlikely to be handling .wav files due to
storage constraints.
However, if there are any other situations where Arch:all files have
endian problems, I will be pursuing those to provide an Arch:any
mechanism if there is a role for such files on embedded devices. .wav
is simply too large for embedded, .gsm is more likely or .ogg.
So the answer to your question, really, is YES. I intend to seek
correct endianness support for any binary format in Debian that does
not already implement it and for which there is a logical reason to
need that format on an embedded device where endianness conversions are
a significant issue.
Music isn't that much of a problem - if a user has to wait a few
hundred clock cycles more to hear a music track is not a big issue.
What does matter is if a user has to wait several dozen clock cycles
*every time any application loads* merely to get the .mo content into
the correct presentation. This is a *MAJOR* usability issue. It will
make the entire OS appear slow in any translated locale.
If Debian wants to be able to support embedded and low resource
machines, Debian has to accept that there will be changes needed to
enable such support.
> (They are "always" little-endian, like .mo files).
>
> I can agree that "it works" is not always a good reason to do things
> in a certain way, but what you are proposing is a change in something
> which is a de facto standard, for very little benefit (saving some cpu
> cycles).
Please remember this is for embedded devices. It works now only becuase
Debian really isn't the Universal OS - lots of parts of Debian are
simply wrong for embedded usage which is why it is taking so long for
Emdebian to make progress.
Nobody cares about a few dozen clock cycles on a dual core GHz amd64 -
but it becomes a quite noticeable delay on an iPAQ. The delay is
repeated every single time any application is started outside the C
locale.
All I'm asking for here is *documentation* that this is how it needs to
be done for certain situations so that others do not make the same
mistake that both you and I have done - assuming that the current
Debian method of Arch:all for .mo is acceptable. It is not, sadly.
> When the cost of something is very high and the benefit is
> very small, the natural thing to do is to keep things as they are.
The cost of this change is irrelevant because the cost of implementing
TDebs is already high and this change does not make that any higher.
Whether TDebs are Arch:all or Arch:any makes no difference to the
amount of work required to implement TDebs in Debian. It merely adds a
tiny amount of work for the buildd network.
The benefits of TDebs (installation sizes, separate translator uploads,
faster translation updates etc.) far, far outweigh the temporary work
of getting them implemented in Debian. It is ludicrous that Debian
insists on installing over 250Mb of *unused and unusable* .mo files
in a default GNOME installation when any one locale needs just 9Mb or
less. (Check the size of your /usr/share/locale/ directory and compare
that with the collected size of the few languages that you actually
speak. Granted that will be a few more than me but I doubt anyone can
speak/read all of the 90+ languages installed by default in Debian.
I'd be surprised if anyone would require more than half a dozen.)
> Anyway, I can forward your suggestion upstream if you insist,
No, I don't see that this needs to be forwarded upstream, this is an
issue within Debian - primarily within the manpage as far as this bug
report is concerned.
All I want is for the manpage of msgfmt to explain that --endianness
{big|little} *is* supported, *why* it is supported and why it is
important for certain situations.
> but I don't
> plan to deviate from upstream gettext if the authors reject your suggestion.
The upstream authors already *explicitly support* endianness because the
option is part of the source code for msgfmt!
(gettext-tools/src/msgfmt.c)
I think upstream may have a better grasp of the issue than you may
imagine because other non-Debian embedded developments can use
--endianness.
Whether or not anything in gettext-Debian changes, I will implement
TDebs using --endianness in calls to msgfmt. All I'm asking is that the
reasons that I have set out for this are clearly explained in the
manpage in Debian so that other developers do not waste time believing
that the current method used for powerful desktop machines is in any
way appropriate for low resource units.
The option exists, it works and the manpage should document it - just
as with any application in Debian. The fact that Debian does not
currently use that option for desktop systems should be mentioned as
long as it is clear that this is not suitable for all devices and that
future support of translations in Debian is likely to use the
--endianness option to ensure compatibility with all supported devices,
not just desktop etc.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpz1Ndy74X4o.pgp
Description: PGP signature
