Date: Sat, 19 Jun 2004 14:07:30 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Thomas-Martin Seck <tmseck-lists@netcologne.de> Cc: freebsd-ports@freebsd.org Subject: Re: CONFLICTS usage question Message-ID: <3D4C2946-C1E9-11D8-9250-00039312D914@fillmore-labs.com> In-Reply-To: <20040619114707.GC568@laurel.tmseck.homedns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4C2946-C1E9-11D8-9250-00039312D914>