Re: pkg/45047: pkgtools/pkg_install minix support

[Alistair Crooks <agc%pkgsrc.org@localhost>]

The following reply was made to PR pkg/45047; it has been noted by GNATS.

From: Alistair Crooks <agc%pkgsrc.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
pkgsrc-bugs%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:
 > >Description:
 > 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
 function.
 
 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
 constituent parts?
 
 Many thanks,
 Alistair