Re: xterm.deb build from Thomas E. Dickey's tree directly
ISHIKAWA Mutsumi wrote:
>
> Hi, all.
>
> I've tried to build new xterm.deb package from Thomas' tree last
> weekend. I think it is 1st step for pruning xterm from xorg-x11 orig
> tarball (it is listed in TODO list of xorg-x11)
>
> Sources and binary (for i386) are available bellow:
>
> http://people.debian.org/~ishikawa/xterm/
>
> * based on xorg-x11 6.8.2.dfsg.1-0pre1v1
> * TODO:
> - {pre,post}{rm,insta} scripts cleanup
> - patch audit (patches are roughly merged from xorg-x11)
I just did most of that for you.
Additional patches from the xfree86 packaging which impact xterm are:
803_gnu_xterm_openpty.diff -- needed for Hurd
059_external_XrenderXftXcursor_programs.diff -- needed for external Render
In xorg-x11 tree:
058_support_external_Xcursor_Xft_Xrender_libs.diff -- New version of 059.
803_gnu_xterm_openpty.diff -- Same as old 803.
That's it; none of the other patches patch anything *in* xterm.
Xterm also appears to be xdm's "failsafe" client, so it might be wise for
xdm to "Recommend" xterm; I don't know.
You'll want (obviously) to check that the same files get installed as in the
build from the main package; Imake is a tricky beast and it wouldn't do to
lose something due to a bad Imake interaction. And if you're switching
from the Imake build to the configure/Make build, it's even more dicey.
I don't think that a debdiff is a good enough method of avoiding regressions
here. You might consider -- and I know this is a bit odd -- doing a build
of the new packaging with the exact version used in the monolithic package,
and doing a full diff between that build and the build from the monolithic
package. That seems like the best way to avoid configuration regressions.
--
This space intentionally left blank.
Reply to: