[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/45047: pkgtools/pkg_install minix support
The following reply was made to PR pkg/45047; it has been noted by GNATS.
From: Alistair Crooks <agc%pkgsrc.org@localhost>
Cc: pkg-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
Subject: Re: pkg/45047: pkgtools/pkg_install minix support
Date: Sat, 11 Jun 2011 19:34:30 +0200
On Fri, Jun 10, 2011 at 03:55:00PM +0000, tcort%minix3.org@localhost wrote:
> Some changes need to be made to pkg_install for it to work properly
> on Minix. The release and version info returned in struct utsname
> is slightly different than on most systems. For Minix 3.2.0,
> release is "3" and version is "2.0". However, most other operating
> systems would store the whole thing ("3.2.0") in release. Also,
> some Minix systems use GNU ar (gar) instead of ar, so configure
> should also check for gar. Additionally, a few header files need to
> be included in some C source files. Lastly, the dependency checking
> should prevent endless recursion for circular dependencies.
Thanks for the diffs - great to see Minix support coming along!
I'd like to see this make it into pkgsrc-2011Q2, but there are a
number of changes here that are lumped together, and I feel that we'd
be better off separating them out and considering them individually.
Personally, I don't like to use assertions in production code. We
have seen too many failures at inopportune moments from systems like
bind for me to believe that it's a good thing. I'd like to replace
the assertions with a check, and return a sane error to the calling
I'd like to split out the dependency stack checks for recursive
dependencies - it's not that it's the wrong thing or that we don't
want it, simply that it's not related to Minix3 support per se.
Can we use the dewey dependency functions for the Minix version
number, or cons up a standard version number as expected from the two
Main Index |
Thread Index |