Bug 34710

++ 07/02/02 16:18 -0500 - Alan Eldridge:
| +.elif defined(CONFLICT)
| +IGNORE= "conflicts with installed ports: ${CONFLICT}"
|  .endif

Don't you want to do some kind of test to see if the ports listed in
${CONFLICT} are already installed?

--pete

--
Pete Fritchman [petef@(databits.net|freebsd.org|csh.rit.edu)]
finger petef@databits.net for PGP key

On Thu, Feb 07, 2002 at 05:59:39PM -0500, Pete Fritchman wrote:
>++ 07/02/02 16:18 -0500 - Alan Eldridge:
>| +.elif defined(CONFLICT)
>| +IGNORE= "conflicts with installed ports: ${CONFLICT}"
>|  .endif
>
>Don't you want to do some kind of test to see if the ports listed in
>${CONFLICT} are already installed?

For right now, I was just setting up a message facility.

To actually check things, we have to do something like the DEPENDS
stuff. This leaves the checking up to the maintainer.

And I'm seeing that our dependency handling is seriously inadequate.
What we do at make time we need to do at pkg_add time, too. See the
thread on ports on XPM libs and dependencies and Mesa.

Oh yeah, the Mesa mess means that if you want OpenGL to work, you have
to rebuild qt from the port if you have XF86-4. May (probably) have to
rebuild all of kde too. 

And how can we get ldd to work on objprelinked .so files? That failure
sucks!

[alane /usr/local/lib]$ ldd libkdeprint.so.0
libkdeprint.so.0:
ldd: libkdeprint.so.0: Exec format error
libkdeprint.so.0: exit status 1
[alane /usr/local/lib]$

-- 
Alan Eldridge
"Dave's not here, man."

There are some patches from Scot Hetzel which support conflicts of both
ports and packages:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13649
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/13650
-- 
Trevor Johnson

On Thu, Feb 07, 2002 at 08:10:18PM -0500, Trevor Johnson wrote:
>There are some patches from Scot Hetzel which support conflicts of both
>ports and packages:
>
>http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13649
>http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/13650

Thanks.

To whomever: you can close my PR in favor of actually doing some work
on those listed above.

However, there's an extra bit of complication we should take note of...
conflicting specifications between packages that actually *can* be resolved.

E.g., installing emacs21 on an X-4.1 system:

emacs21 built with X-3.3 will have a dependency on xpm. xpm will have
a conflict on X-4.1. But that emacs21 package can be installed, and
will work, with X-4.1, as long as we honor the conflict but ignore the
dependency failure that it produces.

It would be almost essential to have a different concept of
dependencies, basically passing all the info from the Makefile through
to the final package, for pkg_add to resolve, if this is to work.

Using the emacs21 case, emacs really doesn't depend on the xpm port(pkg),
it depends on libXpm.so*, which is also supplied by X-libs-4.1. In this
case, the conflicting package satisfied the dependency which failed due
to its presence provoking a conflict.

This is, of course, an extreme case, but there are probably others that
are analogous to this one. Most conflicts won't be from interchangable 
packages, of course.

Note that the reverse case, which happens when you try to upgrade
X-3.3 to X-4.1, means that you have to remove the conflicting package
(xpm).  At this point, all hopes of automagically figuring out how to
Do The Right Thing are lost, though.

Just some food for thought (indigestion is more like it).

Now close this PR. I'll update the other ones with a reference to it.

-- 
Alan Eldridge
"Dave's not here, man."

Comment 5 Patrick Li 2002-02-24 16:39:34 UTC

State Changed
From-To: open->closed

Requested by originator