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