On Thu, 08 Nov 2001, ESR wrote:
Henrique de Moraes Holschuh <hmh(_at_)debian(_dot_)org>:
Or in the absurd mess that the fetchmail makefiles are (INCLUDING the
gettext stuff in them)... I am more afraid of touching the makefiles
than trying to get the stuff under intl/ and po/ to work :(
The fetchmail makefiles are *not* a mess; I understand them and can
Eric, they are more fragile than they should be [in an ideal sense]. This is
in no little part due to the fact that very old gettext was extremely
braindead, but IMHO the needs for a more portable makefile also somehow made
it a bit fragile, as the patches-over-patches accumulated.
I recall one time when a simple change from make -C dir target to cd dir &&
make target broke the makefiles (at least according to some email you sent
me). And they are not very easy to read right now, either.
maintain them. I don't understand gettext's broken, random behavior.
I'm not interested in understanding gettext's broken, random behavior.
That ends *that* discussion.
Indeed, it does. It also starts a big one on my side, which is: should I
drop NLS along with you (if RH 7.2 fails to deliver a non-broken gettext),
or should I try to keep the NLS hooks in Debian?
At this time I am not even sure I have enough time to do so, but I do want
to know if you would be unhappy with someone maintaining a slight fork
(resynched at every new release) of fetchmail with the NLS stuff...
Not again :( ARGH. Eric, I can maintain the gettext stuff for you. As long
as you do not mind using --with-included-gettext yourself when building
fetchmail, that should reduce your gettext problems to nearly nothing.
I don't think having you maintain a critical piece of the build machinery
is really practical. If my build machinery doesn't work because gettext
is broken, the fact that your machinery might work under a different
distribution doesn't help me.
It is your call. It would be awkward, that's for sure. Well, I do know
Debian's gettext maintainer goes to great lenghts to keep that thing working
fine. I have no idea if the people in the RH side do the same, but the fact
is that I never had many problems to get gettext to work under debian, as
long as I did nothing too diferent from what upstream gettext wanted. And
that does mean no weird stuff for solaris's bare-bones gettext in
configure.in, and most definately a very gnu-make'ish makefile.
It helps very very much that we only try to get it to work in a very sane
GNU-only system, though (which RH also is). I do not know if
--with-included-gettext always works sanely under Solaris, for example. It
is supposed to, but that's not much. I recall there was a loooong gap in
gettext releases, which happened during a time the gettext build system was
in a very much fucked up state. That has probably made the problem much
worse.
I understand the value of internationalization. It is just that I am
so fed up with this garbage that the pain does not seem worth the
value. And don't bother trying to raise my perceived value of i18n
because my disgust with gettext is effectively infinite :-(.
Sure thing. Please do understand that there are people who will see it the
opposite way, though. If it has no i18n support, it is not worth the effort
of using -- because they effectively would need a dictionary to do so.
I will unbend this much. I expect to install RH 7.2 shortly. If the 7.2
autoconfig/gettext tools eliminate the problems I've had in the past, I
will not drop gettext support.
I sure hope the RH 7.2 guys did an outstanding effort to get it right this
time, then :)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh