From owner-freebsd-ports@FreeBSD.ORG Sat Jun 19 12:07:47 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7292616A4CE for ; Sat, 19 Jun 2004 12:07:47 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26F5B43D1F for ; Sat, 19 Jun 2004 12:07:47 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from [172.16.0.13] (helo=localhost) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34 (FreeBSD)) id 1Bbed6-000BWr-8R; Sat, 19 Jun 2004 14:07:31 +0200 Date: Sat, 19 Jun 2004 14:07:30 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Thomas-Martin Seck From: Oliver Eikemeier In-Reply-To: <20040619114707.GC568@laurel.tmseck.homedns.org> Message-Id: <3D4C2946-C1E9-11D8-9250-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-ports@freebsd.org Subject: Re: CONFLICTS usage question X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 12:07:47 -0000 Thomas-Martin Seck wrote: > * Oliver Eikemeier (eikemeier@fillmore-labs.com): > >> Besides that your `workaround' has problems (as stated above), try the >> attached ports: >> >> cd /usr/ports/misc/conflicttest2 >> do >> make clean deinstall reinstall >> multiple times. Then do >> make CONFLICT_WITH_SELF=yes clean deinstall reinstall >> >> See the difference? Other examples are possible, but this is probably >> the most trivial one. Furthermore, you get a different error message, >> which is confusing for the novice user. > > So, let's try to get this discussion less emotional and more technical: > > We have a situation where conflicttest-2 has a build dependency on > conflicttest-1. conflicttest-1 conflicts with itself. Yep. > So we want to forcibly reinstall conflicttest-2 and define > FORCE_PKG_REGISTER. Nope. See above: you just deinstall and reinstall conflicttest2. No FORCE_PKG_REGISTER on the command line involved. > This will in in turn force conflicttest-1 to be > built and installed, too. > > Because conflicttest-1 conflicts with itself, the installation of > conflicttest-1 fails with "conflicts with itself" which is, admittedly a > rather confusing, though technically correct message. > > If we disable conflicts checking, everything "works", but if > conflicttest-2 were to conflict with some/port we would not have > caught and we might have hosed some/port. Not good. Plus, you have to set DISABLE_CONFLICTS in the above example, which will just work when conflicttest1 does not conflict with itself. > So the more interesting problem is: is there a way to make the conflicts > generation/check immune to the self-conflict problem. Of course there is, but is it worth the effort? Or, put the other way around: what will this buy us? > The way the > conflicts file is generated is rather primitive: the CONFLICTS pattern > is fed to ls(1) and that's it. IMHO this is buggy. See PR 59696 for an improved version. > How about checking whether we have a > self-conflict and omit this case: > > Index: bsd.port.mk > =================================================================== > RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v > retrieving revision 1.491 > diff -u -r1.491 bsd.port.mk > --- bsd.port.mk 10 Jun 2004 07:30:19 -0000 1.491 > +++ bsd.port.mk 19 Jun 2004 11:42:27 -0000 > @@ -3084,7 +3084,7 @@ > @${RM} -f ${WRKDIR}/.CONFLICTS > .for conflict in ${CONFLICTS} > @found="`${LS} -d ${PKG_DBDIR}/${conflict} 2>/dev/null || > ${TRUE}`"; \ > - if [ X"$$found" != X"" ]; then \ > + if [ X"$$found" != X"" -a "$$found" != > "${PKG_DBDIR}/${PKGNAME}" ]; then \ > ${ECHO_CMD} "$$found" >> ${WRKDIR}/.CONFLICTS; \ > fi > .endfor > > (PKGNAME may not coarse enough as the check criterium since we will miss > the "port conflicts with an older version of itself", but you get the > idea. Does that sound feasible?) It is feasible. You could check PKGORIGINS or do the check-already-installed test before check-conflicts, filtering out previous results. The question remains: Why? -Oliver