Date: Fri, 17 Feb 2012 19:19:29 -0600 From: Zhihao Yuan <lichray@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: Jakub Lach <jakub_lach@mailplus.pl>, freebsd-ports@freebsd.org Subject: Re: recent portrevision bump for libvpx Message-ID: <CAGsORuBnf5nJmtKs1gHCKdwFYNKpRTtDHCiuQsHq2Xk8=xPS6Q@mail.gmail.com> In-Reply-To: <4F3EE006.2080302@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> <CAGsORuBjScOG3V1BykyELtqQhvzk-mKELoVrdUEfOk3Zh4X56w@mail.gmail.com> <4F3EBF4F.6010401@aldan.algebra.com> <CAGsORuDeENz7fWe7pg0=udfcSP-nxN_q8=0agD40gO9fwGCZPA@mail.gmail.com> <4F3EE006.2080302@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 17, 2012 5:17 PM, "Mikhail T." <mi+thun@aldan.algebra.com> wrote: > > On 17.02.2012 17:05, Zhihao Yuan wrote: >> >> On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. <mi+thun@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 >>> 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 libfoo.so 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? The biggest problem of your practice is that: if the major version of lib A updates, some users may not get informed to recompile their ports. Hence, some day, I found my app do not work! But with the existing practice, users will be informed. And, with portupgrade, old lib is kept so the users apps will continue to work, not happen to work. Let say it again: the ports fail to build is not a big trouble; it only means our first defense line is break. The port fails to run correctly is a bigger problem, and it's even bigger problem if the users d not get informed. >> >> -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGsORuBnf5nJmtKs1gHCKdwFYNKpRTtDHCiuQsHq2Xk8=xPS6Q>