Re: pkg/45559

[Hans Rosenfeld <rosenfeld%grumpf.hope-2000.org@localhost>]

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

From: Hans Rosenfeld <rosenfeld%grumpf.hope-2000.org@localhost>
To: Filip Hajny <filip%joyent.com@localhost>
Cc: =?iso-8859-1?Q?J=F6rn?= Clausen <joern.clausen%uni-bielefeld.de@localhost>,
        gnats-bugs%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
pkgsrc-bugs%NetBSD.org@localhost
Subject: Re: pkg/45559
Date: Tue, 8 Nov 2011 15:49:42 +0100

 On Tue, Nov 08, 2011 at 02:00:57PM +0100, Filip Hajny wrote:
 > On 8. 11. 2011, at 13:34, Jörn Clausen wrote:
 > 
 > > Some suggestions:
 > > 
 > > - Provide clean definitions (with builtin.mk et al.) for these tools, so 
 > > that it is possible to define a minimal version in depending packages.
 
 Builtin.mk won't help for tools at all, it is something completely
 differen with a different aim. In fact, builtins usually check
 versions and sometimes even optional features to decide whether to use a
 builtin package or not. For tools, this never done. In fact, tools are
 supposed to be "good enough" regardless of their version. Only if it is
 known to be too old and broken to be any useful, it shouldn't be used at
 all.
 
 For example, most packages work very well with NetBSDs sed, even though
 they formally require a GNU sed, so NetBSD defines
 TOOLS_PLATFORM.gsed=/usr/bin/sed. The few packages that are known to
 really require special GNU features in sed just override TOOLS_PLATFORM.gsed if
 necessary. The same would apply for outdated gmake and other tools.
 
 I'd like to help sort these individual issues out, in fact that's what
 I'm doing bulk builds for.
 
 But I don't think that we should support every outdated or unpatched
 installation that might still exist somewhere. The latest versions of
 the major releases should be sufficient, and the defaults can be
 overridden.
 
 
 > > - Define a single variable "USE_SFW" that can be set to "YES" or "NO".
 
 How about defining TOOLS_PLATFORM.foo or TOOLS_IGNORE.foo if you
 absolutely don't want certain native tools?
 
 > > - Define a new architecture "OpenSol" that has other rules than "SunOS".
 
 That would break a lot of stuff in very interesting ways. No, the
 differences between the individual SunOS flavors just aren't big enough
 to justify that.
 
 > > Personally, I don't see what is gained by using the tools from
 > > /usr/sfw instead of building them from pkgsrc.
 
 It is mostly useful to reduce dependencies, especially on packages
 required for building with a pkgsrc gcc. Which, in turn, is really
 useful to get comparable bulk builds across SunOS versions and
 flavors.
 
 > I'd love to not depend on or use SFW at all.
 
 There is no dependency on it, at least not in the tools framework.
 
 > Also, OPSYS=SunOS is not
 > just Solaris/OpenSolaris any more (whether that begs the platform
 > definition to branch out is another question), and for instance
 > Joyent's SmartOS comes with no SFW tools (or even option of) at all..
 
 Thats why it is detected automatically. OpenIndiana still has /usr/sfw
 for compatibility, but almost all of it are symlinks to the tools in
 /usr/bin or /usr/gnu/bin.
 
 Oh wait, some gcc packages use /usr/sfw/bin/gobjdump and /usr/sfw/bin/gas.
 If that doesn't exist in SmartOS I'll have to fix it.
 
 
 Hans
 
 
 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown