From owner-freebsd-ports@FreeBSD.ORG Sat Jun 19 11:47:19 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 DF98416A4CE for ; Sat, 19 Jun 2004 11:47:19 +0000 (GMT) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8350443D46 for ; Sat, 19 Jun 2004 11:47:19 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-225-54.netcologne.de [213.196.225.54]) by smtp2.netcologne.de (Postfix) with SMTP id 4704E45AD for ; Sat, 19 Jun 2004 13:47:10 +0200 (MEST) Received: (qmail 10747 invoked by uid 1001); 19 Jun 2004 11:47:29 -0000 Date: Sat, 19 Jun 2004 13:47:07 +0200 From: Thomas-Martin Seck To: Oliver Eikemeier Message-ID: <20040619114707.GC568@laurel.tmseck.homedns.org> References: <40D3E41F.3020702@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D3E41F.3020702@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms 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 11:47:20 -0000 * 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. So we want to forcibly reinstall conflicttest-2 and define FORCE_PKG_REGISTER. 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. So the more interesting problem is: is there a way to make the conflicts generation/check immune to the self-conflict problem. The way the conflicts file is generated is rather primitive: the CONFLICTS pattern is fed to ls(1) and that's it. 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?)