[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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>,
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
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
> > - 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
> 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.
%SYSTEM-F-ANARCHISM, The operating system has been overthrown
Main Index |
Thread Index |