From owner-freebsd-ports@FreeBSD.ORG Fri Feb 17 22:05:45 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 77A94106564A for ; Fri, 17 Feb 2012 22:05:45 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 294FF8FC13 for ; Fri, 17 Feb 2012 22:05:44 +0000 (UTC) Received: by ghbg15 with SMTP id g15so2404173ghb.13 for ; Fri, 17 Feb 2012 14:05:43 -0800 (PST) Received-SPF: pass (google.com: domain of lichray@gmail.com designates 10.50.217.130 as permitted sender) client-ip=10.50.217.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lichray@gmail.com designates 10.50.217.130 as permitted sender) smtp.mail=lichray@gmail.com; dkim=pass header.i=lichray@gmail.com Received: from mr.google.com ([10.50.217.130]) by 10.50.217.130 with SMTP id oy2mr13971294igc.10.1329516343652 (num_hops = 1); Fri, 17 Feb 2012 14:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tZNzuWUdnLjSBUQX0h7UG82yYgIwX06V9EXY8GIkcjE=; b=HHq1egKG98UjKvssHkoJrtKOrJHtqNOjEw6aF3IUCiqscOiSaZ6tz8r77XSI7JY5Bt 8k+HcvEucAwj4HiguIQ8+XgCTPGakl/KLPoZmUgph/73yDnGjvVMtXcxPBHwUW6yAYe2 li5z/AoNJbem3zJf0+UiIJiZngH4RUI6iU1pI= MIME-Version: 1.0 Received: by 10.50.217.130 with SMTP id oy2mr11052112igc.10.1329516342854; Fri, 17 Feb 2012 14:05:42 -0800 (PST) Received: by 10.231.61.1 with HTTP; Fri, 17 Feb 2012 14:05:42 -0800 (PST) In-Reply-To: <4F3EBF4F.6010401@aldan.algebra.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> <4F3EBF4F.6010401@aldan.algebra.com> Date: Fri, 17 Feb 2012 16:05:42 -0600 Message-ID: From: Zhihao Yuan To: "Mikhail T." Content-Type: text/plain; charset=UTF-8 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 22:05:45 -0000 On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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. > > 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 > 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. > > 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 > > -mi -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/