Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Mar 2007 17:56:52 -0800
From:      Ade Lovett <ade@FreeBSD.org>
To:        Jean-Yves Lefort <jylefort@FreeBSD.org>
Cc:        Doug Barton <dougb@FreeBSD.org>, freebsd ports <freebsd-ports@freebsd.org>, Ade Lovett <ade@FreeBSD.org>, Kent Stewart <kstewart@owt.com>
Subject:   Re: Ports 104877 causing big problems
Message-ID:  <7CF1749C-3254-46AC-ABDD-BAB0D84ED7A1@FreeBSD.org>
In-Reply-To: <20070310023034.c5939c48.jylefort@FreeBSD.org>
References:  <45F1DDE2.5030404@FreeBSD.org> <BE66AB56-E0B4-420A-910D-9C10DB9AF24D@FreeBSD.org> <45F1EA6A.6070904@FreeBSD.org> <FB399CF7-11E2-4CC9-8C91-7D6850B7B2D8@FreeBSD.org> <20070310023034.c5939c48.jylefort@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mar 09, 2007, at 17:30 , Jean-Yves Lefort wrote:

> On Fri, 9 Mar 2007 17:05:31 -0800
> Ade Lovett <ade@FreeBSD.org> wrote:
>> 3. Ports that *are* affected by this issue (assuming the issue still
>> exists) can be fixed in a more relaxed manner (eg: a conversion of
>> GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying
>> GNU_CONFIGURE=YES]) than a time-T switch.  It will also allow for
>> such affected ports to have PORTREVISIONs bumped by the respective
>> maintainers so as to more clearly identify improved operation to the
>> consumers of those ports.
>
> All ports that use libtool to produce a program or shared library are
> affected by this issue.

This in turn implies that in case that there is an issue, and  
something needs to be done about it, then silently changing the  
semantics of GNU_CONFIGURE is not an appropriate solution.  In order  
for the change, should it be required, to be communicated to all the  
consumers of the FreeBSD ports tree, and not that subset that happens  
to read esoteric discussions on a high volume mailing list, this  
requires that we use the tools available to us, ie: bumping  
PORTREVISION.

1.  Identify if there is still a problem.

2a. If not, get on with something more productive.
2b. If yes, add a new stanza to USE_AUTOTOOLS, for simplicities sake  
we'll call it lthack, which defines GNU_CONFIGURE, and also wanders  
through the configuration files performing the appropriate hackery.

3.  Maintainers that have ports affected by the issue go in to the  
Makefile, chunk GNU_CONFIGURE, add USE_AUTOTOOLS= lthack, bump  
PORTREVISION, and move on to the next one.

The semantics of GNU_CONFIGURE itself don't change, so no chance of  
unintended infra-structural breakdown, full-tree operations are not  
adversely impacted by needlessly including additional Mk/bsd.*.mk  
files, and the update is limited to those consumers of the new  
USE_AUTOTOOLS stanza, without touching bsd.port.mk, thus not  
requiring a full -exp run.  A rather more elegant solution than  
sledgehammer blows which, whilst occasionally needed, soak up huge  
amounts of resource, and are to be avoided if at all possible.

- -aDe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF8hBlpXS8U0IvffwRAnosAKCQDwIx0ogGLiPi62ZxEsPSHE/6dwCfbdFk
XcigDxQoehlavUuScsrabrk=
=Im2J
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7CF1749C-3254-46AC-ABDD-BAB0D84ED7A1>