Wichert Akkerman writes: > Previously [EMAIL PROTECTED] wrote: > > In my new job, I seem to be stuck with HP-UX, tools from the era of > > gcc-2.6, and missing man pages. > > If you're using artemins,hupnos,hit or hitje: they're scheduled to be > replaced.
Ah, good. When, by what? Duh, what a way to find out, btw :-) > > +A new problem is that dpkg/dpkg-deb uses chroot (), which is (on HP-UX)= > =20 > > +only available for the superuser. > > As it should be, this holds for all UNIX systems Ok, but it remains a problem for installations in other places than /, eg, $HOME. Which is typically something you'd do if you're not a superuser? > > - target_cpu=3D"`dpkg --print-architecture`" > > + dnl urg, circular dependency > > + dnl target_cpu=3D"`dpkg --print-architecture`" > > + target_cpu=3D"`expr \`gcc -dumpmachine\` : '\([^-]*\).*'`" > > This breaks: gcc -dumpmachine reports i486-linux, and dpkg > --print-architecture correctly reports i386. I suspect this breaks other > architectures as well. Ah, I 'wondered' why this circular dependency was introduced. What about: dpkg --print-architecture || gcc -dumpmachine | sed 's/i[3-9]86.*/i386/' Alternatively, we'd need a dummy dpkg script for bootstrapping. > > +This is all *very* silly, IMO. I would very much like a bootstrapping= > =20 > > +utility like a package manager to have little as possible requirements > > +--jcn > > If you had read the archives for debian-dpkg your would have seen that Sorry. I didn't see any reference to those archives. Debian-dpkg is a mailing list somewhere? > Ian intends to remove all the automake/libtool stuff. Fact remains that Ah, relief. > any complete development system has those tools though. While that may be true (I've never seen or used these tools before), I still think it would be nice to have an easily portable package management tool. > > +#ifndef HAVE_SYSINFO > > +#define sysinfo linux_sysinfo > > Huh? You assume here that only Linux has sysinfo? No, but similar to the sys_siglist, I've got no manual pages on the subject. Of course, this should be fixed properly, but it didn't seem crucial in this stage. > You also seem to include all the getopt stuff, which isn't used since > dpkg uses its own options handling code? I don't know, I didn't really look into this (I've got other things to do than port dpkg :-), but I encountered missing references to getopt_long. If dpkg is supposed to do option parsing itself, maybe somebody should fix that. No harm to include getopt 'till then? > Anyway I think you need to try this patch on all other architectures Sorry, but I wouldn't know how to do this. I'll try it at home on my linux-ppc box, but that's all the architectures I have to offer (apart from HP-UX :-). Anyway, I think that most changes are enhancements, that shouldn't affect the original behaviour. > first and clean it up a lot first. Of course, I don't expect to get this patch to be used, in this state. Tomorrow I should have a cleaned up version, that doesn't make such a mess of debian/rules. Greetings, Jan. Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien/ | http://www.lilypond.org/
