Date: Thu, 28 Jul 2005 09:29:31 -0400 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: gnome@freebsd.org, kris@freebsd.org Subject: Re: updating security/nss Message-ID: <200507280929.32283@aldan> In-Reply-To: <1122529970.25076.15.camel@shumai.marcuscom.com> References: <200507272315.14407.mi%2Bmx@aldan.algebra.com> <200507280143.43228@aldan> <1122529970.25076.15.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 28 July 2005 01:52 am, Joe Marcus Clarke wrote: = > _Users_ may not care (how do you know, BTW?), but you (the maintainers) = > should. Wouldn't you rather learn, that "test such and such failed", = > than "evolution crashed"? Also, if some change in the OS breaks a test, = > we better learn about quickly -- and with automated tests in post-build = > we will. If you read the change I submitted, you'll see, that the = > vendors' tests run only if BATCH is defined -- is that a compromise? = = I don't see the advantage. In all the years we've had nspr/nss, I've = never seen a major failure. You mean, NSS build was not dying on alpha until OSVERSION 500035? If someone reports a problem, whould not you rather be able to ask them to "please, type make test, and report any test failures"? = And they're great, but users don't know what to do with them, and = these ports have not proven problematic enough to add extra build time = for users. You keep ignoring the fact, that in the changes, I sent you for both NSPR and NSS, the tests will only run automatically if BATCH is defined. I mentioned this at least thrice already -- I suspect, you are not paying much attention to this conversation... I'll repeat. BATCH is set on the package-building cluster (which will let these tests be used as regression tests for the OS on all platforms) and by users, who build non-interactively (and aren't as sensitive to extra 15 minutes of build-time). Why is this not a good compromise? = As a maintainer, I would run the tests upon updates. If users did = start complaining about problems, and we just had a recent OS update, = I could run the tests then as well. One word: BITROT. A friendly automated e-mail from Kris about a build/test failure (with a pointer to build-log) will be much more useful to you, than a "it crashes" report from a user. It will also arrive quicker making it easier to isolate the problem to a recent commit elsewhere. Alright, so you insist on not running these automatically. Make it _possible_, at least, to run them at all. I spent a day fixing NSPR tests runnable and debugging a few odd failures. One of the tests found a real problem in FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/84106 = > Can you give me a URL? = = http://www.marcuscom.com/downloads/nss.diff Ok, thanks, I'll take a look. = > nspr.[2-9]:${PORTSDIR}/devel/nspr = = Okay, so new symbols were added. I don't see why we have to bump the = shared library version since ports will still work with these new = versions. = That will just force users to needlessly recompile ports. No, it would not. The ports, that don't care should, of course, be changed: -LIB_DEPENDS= nspr4.1:${PORTSDIR}/devel/nspr +LIB_DEPENDS= nspr4:${PORTSDIR}/devel/nspr And Gaim, for example, is like that already. = In fact, we're currently looking at a way of keeping all GNOME-related = shared libs at one version number unless ABI backwards compatibility = is broken. That's wrong -- same major number implies both backwards _and forwards_ compatibility. But nspr is not even "GNOME-related" :-) I could not find anything shared library-specific on our sites, but here is a link from a sibling-OS (they use minor numbers too): http://www.openbsd.org/porting/libraries.html That's all theory. Practically, without the major version bump how will a port, that needs the features of the newer version, be able to express that need in LIB_DEPENDS? -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507280929.32283>