Re: Current list of serious problems related to Hurd
On Fri, 24 Nov 2000, Marcus Brinkmann wrote:
> * #68783: dpkg should call exec with full path in argv
> STRATEGY: Includes a working patch which shows what has to be done.
> REASON: Prevents configuration of debconf, which a lot of packages depend
> on, screwing up even the most basic installations.
Show my documentation as to why this must be done. Showing me existing
problems that only happen on the hurd is not documentation.
Other ports of dpkg do not need this. Having this only done for hurd, is not
reasonable. And, there is no reason to place this burden on other ports, as
the other ports work fine.
> * #31620: dpkg: don't use hard coded ENOENT
> STRATEGY: Use Errno.pm ENOENT which is in perl-5.005-base.
> [See also fixed bug report #47204, but note that perl-5.6 gets it wrong
> again!!! I am reopening it and reassigning to perl-5.6-base.]
> REASON: We have thread based errno's, which are different (in the upper
We(dpkg developers) are more than happy to use a symbolic name. However, I am
away of there being continual issues with perl over the years, that causes us
to keep having to hard code it.
Maybe dpkg should have it's open module it includes, that sets up these
defines. That is something I am willing to deal with.
> * #76941: dpkg: [hurd] configure gets the architecture wrong
> STRATEGY: Loosen pattern matching against archtable.
> REASON: Gnu config.guess is i386-gnu0.2, which doesn't match i386-gnu.
> This prevents any native build.
> Broader problems:
> Versioned conflicts (depends) match (not) against provides, screwing up some
> work arounds which we use to fool packages into thinking that we have the
> linux packages installed (shellutils depends on login, which we don't have.
> This screws up basic installs.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com