Bug#53759: revision of the "to build with X support or not" policy

[Raul Miller <moth@debian.org>]

I'm not going to second this proposal.

I think that it misses the real issue in favor of a rhetorical position.

I think that the real reason a package should be built without X support
has to do with the nature of that X support.  If the support is buggy, or
loses functionality which would be available without that X support then
that's a good reason for providing a distinct version without X support.

[In the case of vim, I seem to recall that syntax coloring didn't look
anywhere near as good with x support as in an "xterm-debian" terminal.]

There's also the issue of expensive startup overhead in some marginal
X environments (for example: X over a modem link, or on an old '486),
but this strikes me as a local optimization issue.  I offer the following
shell script to serve for those cases.

#!/bin/sh
# given the full path to a debian program which
# offers X support, suppress that X support,
# unless the program is started with --with-x as the
# first argument.

die() { >&2 echo "$*"; exit 1; }
[ ! -x "$1" ] && die "$1" is not executable
case "$1" in /*) : ok;; *) die you must specify absolute path to $1;; esac

set -eC
dpkg-divert --rename --divert "$1.with-x" --add "$1"
trap "mv '$1.with-x' '$1'" 1 2 3 4 5 6 7 8 
if cat >"$1" <<_____; then
#!/bin/bash
# run without X support, if you want X support:
# you may run $1.with-x
# you may supply --with-x as the first option
# you may mv $1.with-x $1

case "\$1" in --with-x)
	shift
	exec -a "$0" "$0.with-x" "$@"
esac

unset DISPLAY
exec -a "$0" "$0.with-x" "$@"
_____
	chmod +x "$1"
else
	>&2 echo "Uh oh..."
	>&2 echo "Unable to create script for $1"
	>&2 echo "Attempting to undo changes
	dpkg-divert --rename --divert "$1.with-x" --remove "$1"
fi


The script is untested, but I think that it's obvious enough that
if there are any silly mistakes they'll be easy to detect and 
correct.

Thanks,

-- 
Raul