Current "dpkg on Hurd" issues
dpkg 184.108.40.206 still does not deliver a functional dpkg for the Hurd.
Here is a list of all out standing issues I am aware of. Most of them are
known for a long time by now.
* #31620: Use of hard fixed errno ENOENT in some scripts
Wichert says he would ask Jason if apt copes with a predependency on
perl-5.6-base. If it doesn't, it should, but it makes sense to delay the
change until apt can cope if it can't already, if that is not an infinite
amount of time.
* #76941: archtable/configure.in vs i386-gnu/i386-gnu0.2
configure.in should check for the prefix rather than an exact match.
Same issue on some BSD systems, see
* #68783: Calls scripts in /var/lib/dpkg/info without the full path, breaking
debconf. Wichert says he thinks it's a bug in the Hurd, but in any way
the behaviour debconf relies on is not guaranteed by any standard. He said
also he will add the work around, but it hasn't happened yet.
* Depends on sysvinit (>= 2.72), which is not available on the Hurd.
A provides in some Hurd package is not good enough because dpkg can't
cope with versioned dependencies on provided packages last time I checked.
* dpkg-shlibdeps and /usr -> . symlink.
 It's not.
 In my interpretation, a work around for debconf, although I think
Wichert might mean it's a work around for the Hurd. See  ;).