From owner-freebsd-ports@FreeBSD.ORG Tue Feb 25 22:30:21 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58F9010F for ; Tue, 25 Feb 2014 22:30:21 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C756E1291 for ; Tue, 25 Feb 2014 22:30:20 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.128.65]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MLO9y-1WIykI0Gqg-000bbY for ; Tue, 25 Feb 2014 23:30:12 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E108323ED28 for ; Tue, 25 Feb 2014 23:30:10 +0100 (CET) Message-ID: <530D1972.4090309@gmx.de> Date: Tue, 25 Feb 2014 23:30:10 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Support for pkg_* References: <530C5793.2070208@heuristicsystems.com.au> <20140225141144.GA87810@spectrum.skysmurf.nl> <20140225163457.GI83610@ithaqua.etoilebsd.net> <20140225220844.GA92169@spectrum.skysmurf.nl> In-Reply-To: <20140225220844.GA92169@spectrum.skysmurf.nl> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xxs/qKQcuuCJj4vdXkNx8nOIk+i4ogaYlJjDSUAOrRYslIPFHG7 /neGY2Tzlx/FrBwsV5vmKi4Z2Wq6GQUFiH/rgPej9kqH/evi9OTDUZJo5ulAK+nK6JnSHgA 88wVHfQNdwZFro3NG+AuqXNNOFHLTqYlvSn3ELqS/iIL8FBD5IeCs2kW41TzgEJIkbPXw7n ImYJT1ffS007ffzmBS1QQ== X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 22:30:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 25.02.2014 23:08, schrieb A.J. 'Fonz' van Werven: > Indeed: disabling/avoiding staging doesn't fix the actual problem, but it > does usually mitigate the symptom(s) and could in such cases be used as a > temporary workaround for those who - for whatever reason - are disinclined > to wait for the port to get fixed. No, it is not a viable workaround. Any nontrivial port that is converted to staging will usually no longer work without. You would have to roll back the port to the SVN checkout from before the conversion to staging, providing it was intact before. Issues are Missing manual pages, missed post-install scripts, and more. You may find an occasional port that works with some magic command line flags added, but those are exceptions. > I'd even go as far as to say that disabling staging can be used as a > diagnostic tool: if a port that (supposedly) supports staging doesn't > install properly, but does so with staging disabled, it's a pretty safe > bet that the maintainer didn't get the staging bit entirely correct. Of > course it would then be a good idea to notify said port maintainer (and > submitting patches if at all possible), but in this particular case we > didn't even get there. That isn't a diagnostic tool, but a sure-fire recipe to extend the confusion. The reliable diagnostic means are pretty well known: make clean make DEVELOPER=yes check-orphans package And poudriere testport (with proper options according to jail/ports setup) And using the redports.org online service for test builds. It's pretty simple if you can use SVN and a web browser. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlMNGXEACgkQvmGDOQUufZUrIACgsfFb9ciR1eroaNsEUIbLkGz+ /N4Ani4gllgBsQqwYGmTJz6aMzwtfdTs =MJcF -----END PGP SIGNATURE-----