Re: patch: dpkg on HP-UX
Wichert Akkerman writes:
> Previously jcn@wi.leidenuniv.nl 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 <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien/ | http://www.lilypond.org/
Reply to: