From owner-freebsd-ports@FreeBSD.ORG Wed Jun 13 19:45:45 2007 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A159416A48F for ; Wed, 13 Jun 2007 19:45:45 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E29513C50A for ; Wed, 13 Jun 2007 19:45:42 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 53078 invoked from network); 13 Jun 2007 19:45:41 -0000 Received: from unknown (HELO athlon.alexdupre.com) (192.168.178.2) by lab.alexdupre.com with SMTP; 13 Jun 2007 19:45:41 -0000 Message-ID: <46704964.7000205@FreeBSD.org> Date: Wed, 13 Jun 2007 21:45:40 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.0 (X11/20070605) MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <466279CC.8030200@gmx.de> <4663D0B9.4000602@FreeBSD.org> <46701E0B.6010804@gmx.de> <46701FAD.7020204@FreeBSD.org> <20070613173159.GK90672@droso.net> In-Reply-To: <20070613173159.GK90672@droso.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: make update broken X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 19:45:45 -0000 Erwin Lansing wrote: > As I described earlier, SUP_UPDATE, CVS_UPDATE and PORTSNAP_UPDATE are > mutually exclusive and cannot be used at the same time. That it worked > before was an artifact which has been fixed. That is doesn't work > anymore means the designed behaviour finally has been fixed and not > broken :-) As I said before, this is a non-sense: portsnap cannot be used to update src, so it shouldn't prevent to use sup or cvs for such job. I don't know who decided such mutually exclusive behavior, but actually is a (wrong) priority behavior, so the design is still flawed in that sense (if you define SUP_UPDATE and CVS_UPDATE you will use cvs, if you define SUP_UPDATE and PORTSNAP_UPDATE you will get an error). I vote for the enhanced priority behavior: src ports SUP_UPDATE + SUPFILE PORTSNAP_UPDATE CVS_UPDATE SUP_UPDATE + PORTSSUPFILE CVS_UPDATE > Your patch reintroduces PORTSNAP_UPDATE with a new meaning. Previous meaning, not new. Where is defined the official PORTSNAP_UPDATE meaning? > While I > dislike this workaround for an unsupported configuration, it may be > needed for backwards compatability. Please send-pr your patch, but > please also add documentation of the new meaning of PORTSNAP_UPDATE. I'll do it. -- Alex Dupre