recent portrevision bump for libvpx

Mikhail T. mi+thun at
Fri Feb 17 23:17:29 UTC 2012

On 17.02.2012 17:05, Zhihao Yuan wrote:
> On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T.<mi+thun at>  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
>> order.
> 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.
Yes, this is correct. But irrelevant, really -- this will remain true, whether 
or not LIB_DEPENDS lines contain explicit library numbers.
>> 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.

We have not used minor library versions since switch-over to ELF... I do not 
understand, what you are talking about.

>> 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.
The existing practice does not protect against this "bigger trouble" either -- 
whenever port installing is updated, all of the ports LIB_DEPENDing on 
foo.X are matter-of-factly updated to LIB_DEPEND on foo.(X+1). At best, these  
updates are verified to continue to /build/ -- but they are never verified to 
continue to /work/ -- although they usually do work, of course.

`cvs log' shows thousands of commit messages matching the pattern "chas.*bump" 
(libvpx included, of course) -- I'd be surprised to learn, the usability test 
was conducted in 1% of these cases...

>> 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.
No, I should not have to. I might prefer to, but I should not be forced to do 
it. And what's a "major lib" anyway? Does x264 qualify? If I want to add vlc, 
for example, do you want to /force/ me to rebuild mplayer as well -- because 
x264 went from 137 to 171 since I last built it?
>> 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
>> libfoo.
>> 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.

If the port bar is willing to compile against /any/ version of libfoo (and the 
vast majority of ports are), then the problem I described will not strike anyone 
-- bar will built against whatever libfoo is already installed on the building 
computer, and that's it. The user still has an option to upgrade everything to 
the latest, but he is no longer forced to do it just to add one more port to an 
existing install. My proposal will also eliminate the outright build breakages 
like the one, which started this thread.

>> 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
So far, I've presented detailed examples of how the existing practice -- which 
you defend -- breaks things for users and increases maintainers' chores. You 
have not presented any disadvantages of switching to my proposal... I don't 
think, there are any, do you?


More information about the freebsd-ports mailing list