recent portrevision bump for libvpx
lichray at gmail.com
Fri Feb 17 19:24:43 UTC 2012
On Fri, Feb 17, 2012 at 7:59 AM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> On -10.01.-28163 14:59, Jakub Lach wrote:
>> Speaking of recent libvpx update, some ports explicitly look
>> for libvpx.so.0, and fail to update trying to install again libvpx
>> which is already installed.
>> e.g. multimedia/gstreamer-plugins-vp8
> Yet again I'd like to point out, that -- contrary to the wide-spread
> practice -- ports should not, by default, list a particular shlib major
> number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is
> known to cause problems, should the correct version be explicitly given in
I regard this as a wrong practice. Here is why:
1. The way you specify the version in LIB_DEPENDS has NO relation with
how the port link to the lib. The port can link to the major version
(pkg-config), or the .so, etc.
2. One responsibility of the ports system is to protect the user from
suffering from running a software which links to a ABI incompatible,
hence, wrong shared library. A software runs incorrectly is a
disaster, and the shared library version is to prevent this, and the
ports system is to protect the versioned shared libraries. Thus -- A
port fails to find its depends better than it does not link, a
software does not link is better than it does not run correctly. And
your practice is trying to remove such protection.
3. "Known to cause problem"? Can I infer ""you can predict the future"
So, to link to a version explicitly should be the default. Only a
library behaviors "good" in its development history can be considered
to use it's libname only in LIB_DEPENDS.
> freebsd-ports at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
4BSD -- http://4bsd.biz/
More information about the freebsd-ports