>>>> "warly" == warly
<warly(a)mandrakesoft.com> writes:
warly> I have uploaded a new version without this patch
warly> (21.4.11-2mdk).
Do you have "real" development effort (a few hours) to spare to work
on this? If so, what you should do is make the internal treatment of
modifiers indirect. If you can just swap modifiers Meta and Alt, a
patch that makes all user-definable modifiers (ie, modifer bits 1-5)
configurable at build time from ./configure might be acceptable
(although one which ties Meta and Alt to be the same is not). I
believe there's already a comment in the source to the effect that
treatment of modifier bits should be run-time configurable; I'm sure
such a patch would be accepted.
warly> What else should I do to be xemacs devel team compliant?
Mostly tell us when you feel you need to patch XEmacs. In your list
below, none are "wrong", and the one that we can't do much about
ourselves we could at least provide the information to users who build
vanilla XEmacs sources on Mandrake (and to ourselves!).
The "PROBLEM" with Mandrake from our point of view is that XEmacs
built from our sources is noticably misbehaved on Mandrake systems
because the OEM version differs significantly from what we
distribute. And _we_ get the bug reports, which confuse the hell out
of us, because our code should not misbehave in that way on a "normal"
system.
warly> Patch2: xemacs-21.6-non-x86-build.patch.bz2: For PPC buildings.
Probably we want this in the mainstream. If it's been submitted to
xemacs-patches and turned down, maybe you and the authors want to
figure out why and make it work right?
warly> Patch3: xemacs-21.4.6-iso-8859-15.patch.bz2: add ISO 8859-15
This is already done in a forward-compatible way in the latin-unity
package (which also partially solves some of the many problems caused
by conflicts among latin-* character sets). I admit I don't think
latin-unity had been released, maybe not even written, as of 21.4.6.
warly> Patch5: xemacs-21.4.9-fix-emacs-roots.patch.bz2: default
warly> dir for non arch dependent files are share, not lib
This is hard; you'd almost certainly have to maintain this patch
because I don't think we can fix this problem (yes, we acknowledge
it's not right, but the right fix is only trivial for FHS-conforming
systems) in 21.4.
Still, we could put this in PROBLEMS in the form "if you build on
Mandrake, you probably want this unofficial patch for compatibility
with Mandrake file hierarchy layout". We'll still get bug reports,
but not as many, and they'll be quickly solved.
warly> Patch10: xemacs-21.4.10-rpm-spec-mode.patch.bz2:
warly> short-circuit is authorized for packages building in
warly> mandrake.
This relates to rpm-spec-mode? You should be able to put config
information that in default.el (so that users can avoid it with -q) or
site-start.el (if you want to enforce it as Mandrake policy (users can
still avoid it with --no-site-start, but that's deliberately hard to
type). If a patch is required to rpm-spec-mode, you probably need to
negotiate that with upstream authors.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.