recent portrevision bump for libvpx
lichray at gmail.com
Fri Feb 17 22:05:45 UTC 2012
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> On 17.02.2012 14:24, Zhihao Yuan wrote:
> 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.
> I'm sorry, I can not parse the above part. Perhaps, a live example is in
LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
It always links to the latest libpng the time you compile the port.
> 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.
> This is a made-up non-reason, sorry. The only way to get into an ABI
> incompatibility is to have -- at the time of the port building --
> header-files declarations from one version of a library and
> implementation(s) from another. Avoiding such situations is out of the scope
> of the ports-system and this discussion.
> Again, try to come up with a real-life example of how my proposal would
> break ABI for an actual user... You can not.
This only happens when a minor version of a library is not compatible
with another one. OK, that's out of the scope.
> 3. "Known to cause problem"? Can I infer ""you can predict the future"
> from that?
> Yes, you can. Well-knowing the past 15 or so years of the ports-system, I
> can predict some aspects of the future. For example:
> committers will continue to forget to update some of the umpteen instances
> of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo.
> committers will continue to mindlessly bump-up these umpteen instances --
> without actually verifying, that the new version of foo is still acceptable
> to all of those dependants.
My opinion is that, fails to build is not a big trouble, at least we
notified the through portsnap/pkg_version; The user surprisingly finds
that his software fails to run is a bigger trouble.
> port-building will remain unduly difficult because of the wide-spread
> mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the
> following scenario (substitute any of "png", "jpeg", "xml", etc. for "foo"):
The updates to major libs always bind to a larger updates in the ports
tree. You have to upgrade all of the ports depend on them no matter
how you use LIB_DEPENDS.
> You build a shiny new machine -- with the desktop of your choice (KDE,
> Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by
> occasional `config' screens...
> A week later you update your ports tree -- which sees version-bump of
> You try to add a foo-using program bar to your computer -- and fail, because
> the bar-port now insists on the very latest version of libfoo. Not because
> the maintainer of bar determined, that the earlier versions are bad --
> simply because the maintainer of foo went through all dependents and updated
> the LIB_DEPENDS lines in all of them, as is the current sad practice.
> You now have to either portupgrade libfoo -- which means, your desktop will
> be using libfoo.N and the newly-built bar will be using libfoo.N+1
> (inefficient and sometimes a source of problems in its own), or go through
> rebuilding all of the foo-using ports again...
I regards what you said above as the regular routine, and I can't see
how your practice can improve such a routine.
> 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.
> I'm not sure, what you mean by "link to a version". Once again, I beg you to
> offer a live example. Yours,
I mean LIB_DEPENDS= png.6
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