From owner-freebsd-ports@FreeBSD.ORG Mon Aug 25 05:57:37 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79FCCE38; Mon, 25 Aug 2014 05:57:37 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF0731A5; Mon, 25 Aug 2014 05:57:37 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so2287798igb.17 for ; Sun, 24 Aug 2014 22:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nloc8lbvwoVpQPBPFS+MfTxq6eb1u44Tjs/Fb2+6nvw=; b=ci/EmEGhf6//nu31uyz6QkeAYWi9nrjJLJu8QHn3Rq7lJrSiGKkm/sHNli3FnGhU7I ZKlawwoW9MIzDMd8dnAr83IYam2E8CZrky3q/qp3l0Tv/PGDQu3PsnLmui6+pJ7uwlaa Y6Qh1/t2ohojWWbwkGBJNaRRdovsd4laOh0RULI//JfWUzCcq26NqyrFa98ZavU1m+lM NDw/IEDcVLsro34IVisGEyEFY7uukw9z6wELDm+gLOTLkNXbg5G0sNuCfecSbUsX9v3d t2cyb1p8wqpbVt6FC0don+ump/OCYZbqlVJr9eUj2GLDmf/isYrMHda2WRRtzjwmBXzO wxVg== MIME-Version: 1.0 X-Received: by 10.50.62.50 with SMTP id v18mr13233787igr.21.1408946256600; Sun, 24 Aug 2014 22:57:36 -0700 (PDT) Received: by 10.50.237.71 with HTTP; Sun, 24 Aug 2014 22:57:36 -0700 (PDT) In-Reply-To: <20140824191643.005f8e1c@bsd64.grem.de> References: <53F640EF.7000200@FreeBSD.org> <20140824102826.GB9400@home.opsec.eu> <20140824111149.GD9400@home.opsec.eu> <53F9CEDA.4070309@gmx.de> <20140824142050.5e336477@bsd64.grem.de> <20140824191643.005f8e1c@bsd64.grem.de> Date: Mon, 25 Aug 2014 00:57:36 -0500 Message-ID: Subject: Re: HEADS UP: Berkeley DB 4...4.7 port removals/upgrades may require manual preparation From: Scot Hetzel To: Michael Gmelin Content-Type: text/plain; charset=ISO-8859-1 Cc: olli hauer , Kurt Jaeger , ports-list freebsd X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:57:37 -0000 On Sun, Aug 24, 2014 at 12:16 PM, Michael Gmelin wrote: > > > On Sun, 24 Aug 2014 11:59:37 -0500 > Scot Hetzel wrote: > >> On Sun, Aug 24, 2014 at 7:20 AM, Michael Gmelin >> wrote: >> > @Olli: Checking Mk/bsd.databasemk it seems like you're right. It's >> > quite amusing how this went unnoticed for so long, it has been in >> > there for eight years :) >> > >> >> As the original author of the USE_BDB code, the USE_BDB=5 had worked >> in the past. As it is supposed to mean that this port only uses that >> version of BDB. The code was changed on Aug 21 (r365599) and the >> author of the new code might have forgot to test this case. >> > > Not sure if you read the rest of the thread, but this is still working > as intended (I tested using both the old and new version). > > The issue is, that USE_BDB=version means USE_BDB=yes, > WITH_BDB_VER=version, but Kurt has WITH_BDB_VER=6 in make.conf, > which overrides this version number and version =6 is invalid for > devel/ice. So basically it works as designed, Kurt wanted a specific > version of bdb, which doesn't work for devel/ice. > > The fix was to add WANT_BDB_VER= 5 in devel/ice, which I guess is ok, > since this is the only version it really works with (and I guess I > could remove the INVALID directive now, since WANT means really > *want*). > Hmm, I thought I had it implemented this way at one time. Any way. What we should be doing with the WITH_BDB_VER is not overriding the USE_BDB value. Instead we should see if it is a VALID version to use for this port, if it is not, then use the USE_BDB value. So basically the code should be doing the following: USE_BDB=yes - use the default version (48+) or the installed version if higher USE_BDB=yes, WITH_BDB_VER=6 - use version 6 USE_BDB=5 - should mean the same as USE_BDB=yes, WANT_BDB_VER=5 - shouldn't be able to override by setting WITH_BDB_VER=6 - this would also allow the removal of the WANT_BDB_VER variable. - no error should be generated when WITH_BDB_VER is set to an invalid version USE_BDB=48 6 - use (either 48 or 6) or the installed version that matches one of these versions - no error should be generated when WITH_BDB_VER is set to an invalid version USE_BDB=5+, WITH_BDB_VER=48 - use version 5+ or the installed version if higher - shouldn't allow downgrade to a lower unsupported version by setting the WITH_BDB_VER -- should we still display an error in this case or just install the port with bdb 5+? If we make the above changes to the code, then INVALID_BDB_VER and WANT_BDB_VER could disappear. > My question is, what the point of INVALID_BDB_VER really is in this > case, it seems a bit pointless to me given the trouble it caused Kurt > and how we resolved this. Having a fully specified list of supported > versions in WANT_BDB_VER seems better in this case (assuming WANT > supports listing multiple versions). > At the time I had implemented the code, INVALID_BDB_VER was meant to poke holes in the VER+: USE_BDB=2+ INVALID_BDB_VER=3 So the port would be able to use version 2 and 40+, and not 3. Probably should have just implanted it as: USE_BDB=2 40+ and skipped the INVALID_BDB_VER entirely. I was also thinking that we should make WITH_BDB_HIGHEST the default. It is used by VER+ when multiple versions of bdb are installed. That way we can remove this variable also. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised.