From owner-freebsd-ports@FreeBSD.ORG Sat Jun 19 12:46:46 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 3FFE916A4CE for ; Sat, 19 Jun 2004 12:46:46 +0000 (GMT) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97F8743D58 for ; Sat, 19 Jun 2004 12:46:45 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-247-126.netcologne.de [213.196.247.126]) by smtp2.netcologne.de (Postfix) with SMTP id 3023847E4 for ; Sat, 19 Jun 2004 14:46:43 +0200 (MEST) Received: (qmail 13605 invoked by uid 1001); 19 Jun 2004 12:46:58 -0000 Date: Sat, 19 Jun 2004 14:46:36 +0200 From: Thomas-Martin Seck To: Oliver Eikemeier Message-ID: <20040619124636.GD568@laurel.tmseck.homedns.org> References: <20040619114707.GC568@laurel.tmseck.homedns.org> <3D4C2946-C1E9-11D8-9250-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D4C2946-C1E9-11D8-9250-00039312D914@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 12:46:46 -0000 * Oliver Eikemeier (eikemeier@fillmore-labs.com): > 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. Do you mean that we get a "conflicts with ${PKGNAME}" instead of "is already installed". This is confusing, of course. > >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. In this case, it luckily makes no difference, the self-conflict shows up, as described. Sorry for modifying the example. > >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? In my opinion bsd.port.mk should follow the robustness principle: be liberal with regard to the CONFLICTS pattern and silently discard a self-conflict (if it is as easy to spot as I think). I think portmgr's and/or the ports committer's time is simply spent better with improving bsd.port.mk than with chasing down CONFLICTS bugs in >10000 individual ports. Don't forget that maintainers are humans and that the ports system is in general rather liberal. > >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. I do not really like the approach taken there, I'm afraid. > >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? Well, why not? If the already-installed check is done beforehand, the self-conflict message does not show up and the user is not confused. If (s)he forces the reinstall, the self-conflict is silently discarded and the user is still not confused (at least not by the ports system). I definitely think this is worth pursuing.