updating security/nss
Mikhail Teterin
mi+kde at aldan.algebra.com
Thu Jul 28 13:29:39 GMT 2005
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
More information about the freebsd-gnome
mailing list