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

Re: Dpkg for Hurd



On Thu, Jul 16, 1998 at 09:48:06AM -0600, Fulgham, Brent/SCO wrote:

> Bless you Marcus!  I was actually working on this last night, but didn't
> get as far as you did.  I have added my experiences below yours (below):

Oh, well. I was overstating a bit :)  There were "unexpected features"
creaping up, but I have fixed them down to one general problem.
 
> I was using the "latest" in stable.  It has the same sysinfo problems
> (although there IS a sysinfo.h file under /include/hurd/sys -- we could
> probably hack around dpkg to make use of the hurd sysinfo header file.
> Not sure how important this is.

Yes, I assume it isn't much different from 1.4.0.24. Totally unusable for
porting (= a waste of time). 1.4.1.4 is much better.
 
> > * 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.
 
> 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.

Well, I don't know if this is correct. It is what gcc gave me.

I just put this in lib/arch.c:

int dpkg_find_gnu_target_architecture (char *dst, size_t n)
{
  return snprintf (dst, n, "i386-pc-gnu", p);
}

This way we loose all flexibility, but it's a *quick* hack :)

These is a list of latest problems, fixes and so on:

* I needed nsswitch.conf file with "hosts: files" in it --- a known problem
  that causes emacs to segfault (without the file). FIXED!
* The Hurd sometimes messes completely up: So I ended with a few random hd
  blocks (old deleted email) instead of parsechangelog. This is really
  hard to detect, costs a lot of time etc. We *need* the latest development
  sources. If you copy a file, you never know what's in it :)
* Hurd doesn't support lock files, so I had to remove all error checking for
  it (in lib/lock.c). Doesn't matter much because we don't have virtual
  consoles anyway. HACKED!
* 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.

STATUS:
 dselect: comes up, I can choose "Select" and get a list of packages (I
          manually installed in the status and available file).
 md5sum, dpkg-gencontrol, dpkg-parsechangelog, etc:
          Those seem to work fine!
 dpkg-shlibdeps:
          DOES NOT WORK, because LDD IS BROKEN! I replaced ldd with a script
          (echo "LDD IS BROKEN"), and dpkg-shlibdeps runs, warns about the
          messy ldd output and gives up. Well, the ldd script thing is a hack.#
          NOTE: Don't start ldd, it'll hang your machine. "sync" before if
          you really want to try it.
 dpkg: various options work just fine (-s, -l, -S, -L etc).
       Removing a package works!
       Installing a package works up to the configure step (which silently
       fails). Error status? Guess it... 1!
       You end up with "*.dpkg-new" files and such. And the postinst script
       will not be called. Unpacking works, though.
 update-alternatives: fails in my postinst scripts. Says it can't open
       /etc/alternatives/editor, nos uch file or directory... well, isn't much of a
       problem I think.

 joe (the editor): Comes up, let's you edit text and so. One time, writing
       didn't work (so I use emacs now).

Note that I do all my work native on hurd. This is ssllooww :) As I booted
Linux a few hours after hurd hacking, I was surprised about the different :)

If anybody is interested in hacking dpkg, let me know. I can provide patch
files, or so. At the current stage, I would prefer to keep the mess
locally, but if you really want it :)

Marcus, from the dpkg/hurd front.
 


-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


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


Reply to: