NetBSD Problem Report #45559

From www@NetBSD.org  Thu Nov  3 08:29:42 2011
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 287C863CCC4
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  3 Nov 2011 08:29:42 +0000 (UTC)
Message-Id: <20111103082941.8D2F063BC6B@www.NetBSD.org>
Date: Thu,  3 Nov 2011 08:29:41 +0000 (UTC)
From: joern.clausen@uni-bielefeld.de
Reply-To: joern.clausen@uni-bielefeld.de
To: gnats-bugs@NetBSD.org
Subject: revert mk/tools/tools.SunOS.mk to 1.34
X-Send-Pr-Version: www-1.0

>Number:         45559
>Category:       pkg
>Synopsis:       revert mk/tools/tools.SunOS.mk to 1.34
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    hans
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 03 08:30:00 +0000 2011
>Last-Modified:  Sat Nov 26 16:50:02 +0000 2011
>Originator:     Jörn Clausen
>Release:        
>Organization:
University of Bielefeld
>Environment:
>Description:
Please revert mk/tools/tools.SunOS.mk back to release 1.34. 1.35 assigns tools found in /usr/sfw/bin as standards. These tools are usually outdated and much older than the ones found in pkgsrc. E.g. trying to compile devel/gobject-introspection fails early due to an old gmake.

I have tried hard to avoid any reference to /usr/sfw in my local pkgsrc installation. My main reason for using pkgsrc is not to be dependent on /usr/sfw. This change subverts this goal.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->hans
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Fri, 04 Nov 2011 10:16:40 +0000
Responsible-Changed-Why:
Over to committer.


From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/45559
Date: Mon, 7 Nov 2011 17:36:18 +0100

 On what versions of SunOS do you see those problems? What version of the
 tools do they provide? What other packages do fail besides
 devel/gobject-introspection?

 I have not seen any problems w.r.t. tools on Solaris 10u9. Maybe for older
 versions some tools should be explicitly excluded if they are known to
 cause problems. Another possibility would be to fix the few packages
 requiring specific versions of tools to actually check the version of
 native tools.


 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, hans@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/45559
Date: Tue, 08 Nov 2011 13:34:46 +0100

 >   On what versions of SunOS do you see those problems? What version of the
 >   tools do they provide? What other packages do fail besides
 >   devel/gobject-introspection?

 $ uname -a
 SunOS pkgsrc-i86 5.10 Generic_142901-03 i86pc i386 i86pc

 $ /usr/sfw/bin/gmake --version
 GNU Make 3.80

 $ /usr/pkgsrc/head/bin/gmake --version
 GNU Make 3.82

 $ /usr/sfw/bin/gtar --version
 tar (GNU tar) 1.22

 $ /usr/pkgsrc/head/bin/gtar --version
 tar (GNU tar) 1.26

 I have seen this problem only with devel/gobject-introspection, but I 
 wasn't able to update any packages lately. Anyway, I see this more as a 
 general issue, not something that should be solved package by package.

 >   I have not seen any problems w.r.t. tools on Solaris 10u9. Maybe for older
 >   versions some tools should be explicitly excluded if they are known to
 >   cause problems. Another possibility would be to fix the few packages
 >   requiring specific versions of tools to actually check the version of
 >   native tools.

 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.

 - Define a single variable "USE_SFW" that can be set to "YES" or "NO".

 - Define a new architecture "OpenSol" that has other rules than "SunOS".

 Personally, I don't see what is gained by using the tools from /usr/sfw 
 instead of building them from pkgsrc. Reasons for native packages IMHO 
 are 1) They are large and have many dependencies (not the case for the 
 tools we are talking about) or 2) They provide vendor support (e.g. 
 special purpose hardware) that is not available via pkgsrc. This is also 
 not the case.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: "Filip Hajny" <filip@joyent.com>
To: =?iso-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
Cc: <gnats-bugs@NetBSD.org>,
	"Hans Rosenfeld" <rosenfeld@grumpf.hope-2000.org>,
	<hans@NetBSD.org>,
	<gnats-admin@NetBSD.org>,
	<pkgsrc-bugs@NetBSD.org>
Subject: Re: pkg/45559
Date: Tue, 8 Nov 2011 14:00:57 +0100

 On 8. 11. 2011, at 13:34, J=F6rn Clausen wrote:

 > Some suggestions:
 >=20
 > - Provide clean definitions (with builtin.mk et al.) for these tools, so =
 that it is possible to define a minimal version in depending packages.
 >=20
 > - Define a single variable "USE_SFW" that can be set to "YES" or "NO".
 >=20
 > - Define a new architecture "OpenSol" that has other rules than "SunOS".
 >=20
 > Personally, I don't see what is gained by using the tools from /usr/sfw i=
 nstead of building them from pkgsrc. Reasons for native packages IMHO are 1=
 ) They are large and have many dependencies (not the case for the tools we =
 are talking about) or 2) They provide vendor support (e.g. special purpose =
 hardware) that is not available via pkgsrc. This is also not the case.

 I'd love to not depend on or use SFW at all. Also, OPSYS=3DSunOS is not jus=
 t Solaris/OpenSolaris any more (whether that begs the platform definition t=
 o branch out is another question), and for instance Joyent's SmartOS comes =
 with no SFW tools (or even option of) at all.

 -F=

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: Filip Hajny <filip@joyent.com>
Cc: =?iso-8859-1?Q?J=F6rn?= Clausen <joern.clausen@uni-bielefeld.de>,
        gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
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

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, hans@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/45559
Date: Tue, 08 Nov 2011 17:24:26 +0100

 On 11/08/11 03:55 PM, Hans Rosenfeld wrote:
 >   >  >  - 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?

 I do not want to avoid certain tools, I want to avoid /usr/swf all 
 together. And as I don't want to skim tools.SunOS.mk on a regular basis 
 and check for new replacements, such a global flag is one solution I can 
 accept.

 >   >  >  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.

 Huh??? Instead of using the same tools from pkgsrc you suggest to use 
 different tools from different SunOSes to get comparable results??? 
 Sorry, I don't buy that.

 >   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.

 And that's the reason why I think a split between SunOS and everything 
 spun off from OpenSolaris is inevitable. If even /usr/bin is not 
 compatible any more, a clear distinction between these two strains is 
 necessary. I do see the problem that the number of "old" SunOS users 
 will get smaller over time, and support for this OS in pkgsrc will 
 vanish. But I prefer this path over one where changes to pkgsrc based on 
 assumptions made on OpenSolaris et al. break things on Sol10 and before.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/45559
Date: Sun, 13 Nov 2011 19:08:14 +0000

 On Tue, Nov 08, 2011 at 04:25:05PM +0000, J?rn Clausen wrote:
  >  And that's the reason why I think a split between SunOS and everything 
  >  spun off from OpenSolaris is inevitable. 

 I think this is a good idea, even if the support for the "real"
 Solaris goes slowly down the drain like the IRIX support. The question
 is, how many different ways does the split have to go to take account
 of all the OpenSolaris forks?

 (note: I have no direct stake in this, the last time I used Solaris
 was in 2000 and I was very happy to be able to rm -rf it.)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@netbsd.org
Cc: =?iso-8859-1?Q?J=F6rn?= Clausen <joern.clausen@uni-bielefeld.de>
Subject: Re: pkg/45559
Date: Sat, 26 Nov 2011 17:47:12 +0100

 On Tue, Nov 08, 2011 at 05:24:26PM +0100, Jörn Clausen wrote:
 > On 11/08/11 03:55 PM, Hans Rosenfeld wrote:
 > >  >  >  - 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?
 > 
 > I do not want to avoid certain tools, I want to avoid /usr/swf all 
 > together. And as I don't want to skim tools.SunOS.mk on a regular basis 
 > and check for new replacements, such a global flag is one solution I can 
 > accept.

 Ok, adding such a flag might be useful, even if only to set by default
 on 5.8 and 5.9.

 Let's see what we have in there from sfw:

 ggrep:
   I think you always want that if you have it. I'm not aware of any way
   to specify that a grep with GNU extensions is required.  There are
   lots of packages that want to use grep -q or something like that, so
   if its there, use it.

 greadelf:
   I highly doubt that depending on devel/binutils really makes sense
   here. IIRC devel/binutils is quite outdated itself.

 makeinfo, install-info:
   mk/tools/texinfo.mk takes care of this already, packages can set
   TEXINFO_REQD to require a minimum version

 texi2html:
   I've seen problems with that when packages use arguments that the
   native texi2html doesn't know. That's usually easy to fix.

 gmake, flex, bison:
   I've just added mk/tools/gmake.mk and mk/tools/flex.mk to take care of
   the versions. I added GMAKE_REQD=3.81 to devel/gobject-instrospection
   and FLEX_REQD=2.5.33 to emulators/wine*. The same could be done for
   bison, if necessary. I'd really prefer to individually fix the few
   packages requiring this.

 gtar:
   I'm not sure about this. There are some things failing with 1.23 on
   5.10 because of broken distfiles (like, boost distfile using too large
   gid values). I'm still trying to figure out how to work around this in
   packages known to be affected. For everything else, I think using it
   causes no harm.


 So do you think I should exclude some of those tools from USE_SFW?

 Would you be willing to help sort out which packages need which special versions?


 > >  >  >  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.
 > 
 > Huh??? Instead of using the same tools from pkgsrc you suggest to use 
 > different tools from different SunOSes to get comparable results??? 

 Same pkgsrc compiler with the same set of dependencies -> comparable
 results. If gcc pulls in gmake, which pulls in gettext, which pulls in
 libtool-base, which then configures itself for some other compiler,
 some things break in interesting ways later.

 Although it does happen, it is quite uncommon that a package really
 requires a certain version of a tool. We should fix that individually.


 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.