Johnny C. Lam wrote:
> On Wed, Jul 31, 2002 at 01:27:13AM -0700, julien.letessier@sun.com wrote:
> 
> I've taken a slightly different approach to modifying the buildlink.mk
> files that should accomplish the same thing as your proposed patches.
> From the commit log:
> 
> -------
> Create new variables INCOMPAT_ZLIB, INCOMPAT_BZIP2, INCOMPAT_READLINE,
> INCOMPAT_GETTEXT that are analogous to INCOMPAT_ICONV and contain lists of
> shell wildcards intended to match against ${MACHINE_PLATFORM}.  These
> variables are used to note those platforms that have the named packages in
> the base system but are incompatible in some way from the pkgsrc version
> of the same package.  Change INCOMPAT_CURSES to have the same sematics as
> above.  These variables allow much greater precision in specifying which
> platforms have broken (for the purposes of pkgsrc) versions of software in
> the base system that must be ignored.
> 
> The buildlink.mk files for these packages define private _INCOMPAT_*
> versions of these variables, and they contain the default lists of
> platforms that are known to have incompatible software bits.

Hi Johnny,

This method is IMHO extremely satisfying, even though it complexifies 
the buillink.mk "API" a little.

> The appropriate places to note these incompatibilities is in the individual
> buildlink.mk files for these packages.  I've started with:
> 
> 	_INCOMPAT_ZLIB=		SunOS-*-*
> 	_INCOMPAT_GETTEXT=	SunOS-*-*
> 
> The benefit is that we are able to name the "bad" platforms much more
> precisely.  If you are familiar with the various versions of Solaris, do
> you think you can narrow the above wildcard patterns to something more
> appropriate?  Also, could you supply good definitions for _INCOMPAT_BZIP2,
> _INCOMPAT_NCURSES, _INCOMPAT_ICONV, and _INCOMPAT_READLINE?

I've (informally) chatted with a few guys here in the Labs about this 
subject. None of us know Solaris enough to give a precise answer, but 
Solaris tends to carry arround different versions of these different 
libs, sometimes broken, sometimes not, and generally with only one set 
of non-standard headers.

Even worse, a single version of Solaris (e.g. Solaris 8) can have 
different versions of the standard libs, depending on what patches the 
sysadmin applied ('Service Packs'), which can be broken or not, 
compatible or not. For instance, a service pack can replace libfoobar 
with a newer, incompatible (or patched) version... and thus break your 
pkgsrc-compiled software :(

This leads to a pretty dark picture when it comes to compiling 
third-party software on Solaris. Our conclusions were that loosing a few 
megs of disk space by using the (reliable) pkgsrc libs was probably the 
best solution... as it probably is for most proprietary OS, which have 
opaque policies concerning 'default' software bits.

<troll> Except MacOS X, of course, since it only is a masqueraded 
FreeBSD ;) </troll>

Conclusion: SunOS-*-* is IMO the best incompatibility definition you can 
give for all these libs, but I'm open to suggestions :)

BTW, I'm CCing to tech-pkg, since this thread can be of interest  for 
the folks out there (hi list!).

Cheers,
-- 
Julien T. Letessier
Sun Labs Europe, Meylan, France
julien.letessier@sun.com