Re: [configure: feature request] Support configuration like `i386-linux'.

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: 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 Debian> distribution. 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> 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.[1] 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 Debian> distributions. 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 a terrible reason to break standard on something that is behind the scenes in any case. Footnotes: [1] 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."