Re: Current "dpkg on Hurd" issues
Previously Marcus Brinkmann wrote:
> * #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.
Will fix, partially in perl partially by rewriting dpkg-dev things in
python.
> * #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
> http://lists.debian.org/debian-dpkg-0011/msg00017.html
It works fine on FreeBSD and OpenBSD actually.. need to reread that.
> * #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[1], but in any way
> the behaviour debconf relies on is not guaranteed by any standard. He said
> also he will add the work around[2], but it hasn't happened yet.
Just fixed this in CVS.
> * 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.
Still can't unfortunately.
> * dpkg-shlibdeps and /usr -> . symlink.
> See http://lists.debian.org/debian-dpkg-0102/msg00006.html
I'll reread that, I'm rewriting dpkg-shlibdeps now anyway since the
current code is somewhat, euhm,
> [1] It's not.
It's a definite non-UNIXism at the very least.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wichert@cistron.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: