Re: Stop building 21.5 nomule
Ar an seachtú lá is fiche de mí Feabhra, scríobh Stephen J. Turnbull:
Mats> OK. So either the offending packages need to go
strictly
Mats> ISO-8859-1 or move out to mule-packages. Right?
Yes. I don't like it, but something is necessary, and that is the
best policy we were able to come up with. However, nobody's thought
about it for a long time, so I'm open to suggestions. (They need to
be gradual and backward-compatible, though, for 21.4.)
The offending packages need to go strictly iso-8859-1--there’s no need,
beyond supporting no-Mule, for them to be in mule-packages, and the
information can be preserved easily in 8859-1.
I'd like to work on this, but I'm currently over-promised.
Maybe
Aidan or Ben will, though.
I should mention that Ben talked about putting at least a UTF-8 codec
into 21.4, which would theoretically allow us to remove the
distinction between xemacs-packages and mule-packages for all future
versions of XEmacs.
He suggested it; we pointed out that would involve hacking Mule-UCS; he
thought better of it.
21.5 no-Mule should be able to handle ISO-8859-1 coding cookies, because it
does support the coding system API. If the ISO-8859-1 coding cookies (not
just the iso-2022-7 ones) are indeed breaking the build--as the proposed
band-aid seems to imply--then that’s a recent bug in 21.5.
I don't recall a transition strategy though. Doing the coding
system
wouldn't be hard, I think. The hard part is arranging that "old" non-mule
XEmacsen get no-mule packages. I think this would probably involve some
duplication across the mule/xemacs hierarchies.
--
In the beginning God created the heavens and the earth. And God was a
bug-eyed, hexagonal smurf with a head of electrified hair; and God said:
“Si, mi chiamano Mimi...”