karlheg(a)inetarena.com (Karl M. Hegbloom) writes:
> I would like if I could say `configure i386-linux', rather
> `configure i386-debian-linux'. Here's why (one paragraph at
> top of page):
I think you're missing the point. See Chapter One:
Debian> 1.1 Scope
Debian> This manual describes the policy requirements for the
Debian> Debian GNU/Linux distribution. This includes the structure
Debian> and contents of the Debian archive, several design issues
Debian> of the operating system, as well as technical requirements
Debian> that each package must satisfy to be included in the
This is instructions to _Debian package maintainers_, not to the
upstream development organization. So the architecture spec string is
NOT something that XEmacs.org
is under any pressure from Debian to
change. Rather, _you_ (AFAIK you are the DPM in question) should fix
(if fix it is) this in $XEMACS_SRC/debian.
If a configure wizard wants to help you with that, OK. But as Kyle
(14428.15768.783067.223883(a)crystal.WonderWorks.COM>) points out,
making this change means that Debian autoconfs are going to always be
broken with respect to everything else in the GNU world; I think this
policy is going to have to get "clarified." I think you should ask
the Debian cabal if they really meant what they seem to mean, or if
they meant "another idea by the same expression."
Have you checked other GNU autoconf-using programs in the Debian
distribution to see how this is handled?
>>>> "Jan" == Jan Vroonhof
Jan> That idea seems broken to me. Configure machine types always
Jan> have been been triples.
I agree. God save us all if we had no way to identify vendor when
vendor == Red Hat. But the principle is the same with all
distributions; they all patch their libs, they all provide different
features in different ways, and that vendor ID is useful.
Debian> Note, that we don't want to use `<arch>-debian-linux' to
Debian> apply to the rule `architecture-vendor-os' since this
Debian> would make our programs incompatible to other Linux
But some of them are, anyway, due to differences in compliance to say
the FHS or placement of configuration files, etc.
Note that they proceed to give the whole game away by admitting that
they think vendor == "unknown" "does not look very good." That's
terrible reason to break standard on something that is behind the
scenes in any case.
 Well, at least as of late 1997. They may have gotten their act
together since then.
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."