From owner-freebsd-ports@FreeBSD.ORG Fri Feb 17 20:57:58 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720F1106566B for ; Fri, 17 Feb 2012 20:57:58 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id CC1538FC08 for ; Fri, 17 Feb 2012 20:57:57 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 17 Feb 2012 15:57:56 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BPD55465; Fri, 17 Feb 2012 15:57:52 -0500 Received-SPF: None identity=pra; client-ip=209.6.63.29; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="mi+thun@aldan.algebra.com"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=209.6.63.29; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="mi+thun@aldan.algebra.com"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=209.6.63.29; receiver=smtp01.lnh.mail.rcn.net; envelope-from="mi+thun@aldan.algebra.com"; x-sender="postmaster@utka.zajac"; x-conformance=sidf_compatible X-Auth-ID: anat Received: from 209-6-63-29.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO utka.zajac) ([209.6.63.29]) by smtp01.lnh.mail.rcn.net with ESMTP; 17 Feb 2012 15:57:52 -0500 Message-ID: <4F3EBF4F.6010401@aldan.algebra.com> Date: Fri, 17 Feb 2012 15:57:51 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111013 Thunderbird/7.0.1 MIME-Version: 1.0 To: Zhihao Yuan References: <4F3E289D.9050605@FreeBSD.org> <4F3E2CED.90601@FreeBSD.org> <4F3E3537.9040105@FreeBSD.org> <1329478316415-5492205.post@n5.nabble.com> <4F3E5D41.9050503@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jakub Lach , freebsd-ports@freebsd.org Subject: Re: recent portrevision bump for libvpx X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:57:58 -0000 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