Opinion on cross-port OPTIONS CONFLICTS
josh at tcbug.org
Fri Dec 21 13:24:27 PST 2007
I've recently run across some brokeness in ports that would be relatively
trivial to deal with if one port had a way to know about the OPTIONS another
port was compiled with.
My initial thought was to register the state of OPTIONS in to /var/db/pkg.
This solves all of the problems that I know of (not that I know all of them,
but it fixes what I've found that's broken) but also involves quite a bit of
work to the pkg_* tools.
It was suggested to me that one could set up something such that
CONFLICT_FILE=blah which would cover the case of an OPTION in another port
causing it to install files that it wouldn't otherwise. This is far far
easier to impliment, but does not solve all of the problems I've found.
Another suggestion was to list the state of OPTIONS in the package name. I
haven't really chewed on this one much.
Here are two examples of situations where things are broken and it's tough to
fix under the existing infrastructure:
1) random-example-app has ruby support but breaks with a threaded ruby
installation. (CONFLICT_FILE wouldn't help here)
2) subversion and apache22 can overwrite each other's apr if you don't tell
them about each other. Here's an example of how to duplicate this:
install subversion without -DWITH_APACHE2_APR so it installs it's own apr.
install apache22 and don't select use apr from ports from the menu.
deinstall subversion. It will complain that md5s are wrong on apr because
apache installed it's own there.
Obviously this is doing it wrong, but in my opinion ports shouldn't be able to
overwrite each other.
Anyways, suggestions/feedback welcome.
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071221/13fd91ed/attachment.pgp
More information about the freebsd-ports