Re: Current list of serious problems related to Hurd
On Sat, May 18, 2002 at 03:01:10PM -0500, Adam Heath wrote:
> On Fri, 24 Nov 2000, Marcus Brinkmann wrote:
>
> > * #68783: dpkg should call exec with full path in argv[0]
> > 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.
This was discussed long and broadly back then. Debconf relied on a specific
behaviour in the way shell scripts were invoked which was not specified by
any oeprating system standard. Most systems behave like debconf expected it,
but some don't. The Hurd would behave like it expected, if it were
possible, but it isn't possible for security reasons (the modular structure
of the Hurd introduces some barriers of trust between components that are
usually in the same trusted component in systems like BSD and Linux).
I just checked, and all the details are in the bug report. Anyway, this
was worked around a long time ago. If you want to revert this change, then
it would be nice until we have fixed debconf first, if it still relies on
this behaviour (if it doesn't, I don't care). Debconf parsed the invocation
name of the script to get the package name, which is probably not the most
sane thing to do anyway, so I would actually encourage fixing this if it
is still done this way.
> Other ports of dpkg do not need this.
Well, we are aware that the Hurd is different in such details from
traditional Unix systems. We are sometimes different within standard
behaviour (eg where POSIX offers a choice) and often in behaviour not
standardized. But we are not different just to be different, we often
change the default to be like existing systems (BSD or GNU/Linux), if there
is not a hard reason to do otherwise.
In this specific case, it could not be done differently.
> Having this only done for hurd, is not
> reasonable.
In this specific issue, you might find other systems to behave like the Hurd.
> And, there is no reason to place this burden on other ports, as
> the other ports work fine.
Sorry, which burden? The change did not effect execution time or anything
like that in the least.
> > * #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
> > bits).
>
> 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.
The current version uses a small program /usr/lib/dpkg/enoent, which returns
the error number ENOENT, and doesn't 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.
Perl also has the -e operator, which tells you if a node exists (this could
be used to test for non-existance of files). OTOH, Wichert seems to be
rewriting it all in python anyway.
> > * #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.
>
> Fix archtable.
Well, i386-gnu-0.2 was then added at some time. The better way to fix it is
to not use an archtable file at all, but to use loose pattern matching on
the autoconf host variables in configure. Or use pattern matching in
archtable.
> > 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.
>
> Huh?
Well, I learned later that it is preferred to fix this by changing the
dependencies of a package based on the architecture, so this issue is mostly
mood. This doesn't work for binary all packages, though.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: