On Tue, Jun 26, 2007 at 07:21:00AM -0400, Michael Stone wrote: > On Tue, Jun 26, 2007 at 08:26:37AM +0200, Steffen Grunewald wrote: > >On Mon, Jun 25, 2007 at 11:11:06AM -0400, Michael Stone wrote: > >>Well, that's a mistake on their part, assuming distribution-specific > >>output from a standard tool. > > > >well, it might be. But the result is that under Debian the installation > >fails while it works with RH, Fedora, ... you name it. > > hmm. Is there any chance that the installation script was *designed* to > work on those distributions? (I note that you list two redhat > variants...what does slackware do, for example?) > > >Debian seems to > >be the only distro that returns "unknown" when queried for the processor > >type. This is embarassing ... it should be easy to return the same value > >as for machine type, isn't it? > > That would be incorrect; the details are in the bug log. If the machine > type were what you were looking for, why not just use uname -m? (And > forward that suggestion upstream.) If you look at the posix standard for > uname, there is no such thing as a -i or a -p: > http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html > On openbsd, e.g., you'll get nothing for uname -i and a long text string > for uname -p. I'm fairly certain that redhat used to return something > long and hideous for uname -p as well, so I wouldn't rely on any > particular output from a non-standardized option.
OK, I see the point to some amount at least. Still I'm wondering why we do not fill in something more useful than "unknown" - the processor type is not completely unknown to us admitted that this info is already in the machine type. Adding Fedora's (taken from FC6 source package) "coreutils-4.5.3-sysinfo.patch" to the debian/patches directory produced the correct (in Globus' sense) behaviour, so I will live with my own patched-up packages for now. Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
