[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dpkg for Hurd



Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> > > * Biggest problem: dpkg --print-architecture. I tried to hack it
> > >   but gave up. Someone else has to change lib/arch.c to support
> > >   GNU archhitecture.
> > > 
> > I ran into a problem where the configure macro AM_GNU_GETTEXT is not
> > defined.  I grepped around in my Linux directories, but couldn't find
> > the proper macro file.  This is probably very easily fixable.  Anyway,
> > this broke some of the aclocal/automake stuff.
> 
> I just copied "/usr/bin/aclocal" (a perl script) and /usr/share/aclocal/ to
> my GNU partition. IIRC, this fixed this problem, but there are more. For
> example, libtoolize is also needed. Maybe it is doable, but I went over to
> dpkg 1.4.1.4, and have spent so much time on it that I think it would be
> wasted to go back.

aclocal is a part of gettext.  I forgot about needing that.  I'd just use
the sources from hamm.

> > We probably need to create a decent architecture identifier (i.e.,
> > i586-gnu-hurd) somewhere so that these get-architecture macros can find
> > something meaningful.
> 
> I choosed i386-pc-gnu. It is CPU-MANUFACTURER-KERNEL-OS or
> CPU-MANUFACTURER-OS.

If I remember correctly, the proper solution to this is to specify
the architecture on the command line to configure, for your choice:

./configure i386-pc-gnu

> * The Hurd does not return correct error status. A call to exit() ever
>   returns exit status 1. This is bad! because dpkg calls subprocesses
>   extensively and will stop working when they seem to fail.
>   In exit(int status), status is de-facto ignored (set to 1).
>   Therefore, dpkg --build fails, because it calls dpkg-deb, which returns
>   with exit().
>   FIX: Let dpkg ignore error status. I tried this in lib/mlib.c:
>     n = WEXITSTATUS (status);
>     if ((n != 0) && (n != 1)) {
>                  ^^^^^^^^^^^
>       ohshit (_("subprocess %s terminated with error status %d"),
>         description, n);
> 
>   It *seemed* to work.

Shudder.

If statements in #!/bin/sh scripts won't work properly till this
is fixed.  && and || will be useless as well.  Installations won't
be reliable, and it will be pure luck (or a lot of manual work) if
you manage to install a working system.

-- 
Raul


-- 
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: