Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2012 15:57:51 -0500
From:      "Mikhail T." <mi+thun@aldan.algebra.com>
To:        Zhihao Yuan <lichray@gmail.com>
Cc:        Jakub Lach <jakub_lach@mailplus.pl>, freebsd-ports@freebsd.org
Subject:   Re: recent portrevision bump for libvpx
Message-ID:  <4F3EBF4F.6010401@aldan.algebra.com>
In-Reply-To: <CAGsORuBjScOG3V1BykyELtqQhvzk-mKELoVrdUEfOk3Zh4X56w@mail.gmail.com>
References:  <4F3E289D.9050605@FreeBSD.org> <4F3E2CED.90601@FreeBSD.org> <4F3E3537.9040105@FreeBSD.org> <1329478316415-5492205.post@n5.nabble.com> <4F3E5D41.9050503@aldan.algebra.com> <CAGsORuBjScOG3V1BykyELtqQhvzk-mKELoVrdUEfOk3Zh4X56w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 order.
> 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.
> 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.
  * 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"):
     1. 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...
     2. A week later you update your ports tree -- which sees version-bump of
        libfoo.
     3. 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.
     4. 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...

> 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,

    -mi




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3EBF4F.6010401>