updating security/nss

Joe Marcus Clarke marcus at marcuscom.com
Thu Jul 28 05:53:19 GMT 2005


On Thu, 2005-07-28 at 01:43 -0400, Mikhail Teterin wrote:
> On Thursday 28 July 2005 12:34 am, Joe Marcus Clarke wrote:
> = > Great. I hope, you'll find it possible to use some of the features
> = > of my version nevertheless. In particular:
> = > 
> = > 	. do not build/use NSS' own version of -lz;
> = > 	. do not build/use NSS' own version of db (patch-sysdb);
> = > 	. patch the tests, so they can be used automatically;
> = > 	. fix a lot of compiler warnings and some warning-identified
> = > 	  bugs.
> 
> = The tests will not be run automatically. Most users don't care about
> = this,
> 
> _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.

> 
> = and Kris is working on creating a regression framework for package
> = builds on the cluster.
> 
> Whatever regression framework Kris (CC-ed) comes up with, it should
> be using software vendors' own self-tests, whenever such tests are
> available. In fact, one of the ways to do it would be to check if a port
> has a "test" (or "do-test") target.

Yep.

> 
> My version of the update (for both NSPR and NSS) provide such a target
> to each and I've spent considerable amounts of both time and effort to
> make the tests easy to run and to avoid bogus failures.
> 
> These are live and kicking regression tests available today...

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.

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.

>  
> = As for the other things, you're free to modify the diff I sent out to
> = the gnome list.
> 
> Can you give me a URL?

http://www.marcuscom.com/downloads/nss.diff

> 
> = > P.S. I just realized, that our recent upgrade of devel/nspr
> = > should've bumped the major library version(s) :-( The new version
> = > provides some stuff, that is required to build the browsers --
> = > without the major number bump, the browsers will not be able to
> = > LIB_DEPEND properly.
> =
> = The browsers use their own version of nspr.
> 
> They should not. I'm attaching your e-mail from 6 months ago, which
> points at the then-current NSPR being too old as the only barrier to
> using it instead of browsers' own versions. That e-mail prompted me
> to file:
> 
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=276891
> 
> which was finally (partially) solved a few weeks ago...
> 
> Browsers' configure scripts have the
> 
> 	--with-system-nspr
> 
> option and we should definetly use it. Installing include/mozilla/nspr,
> include/firefox/nspr, and include/nspr is SO WRONG, I can't believe, we
> are even discussing this...
> 
> On top of that, we should consider something like --with-system-nss too.
> 
> At any rate, the need for the major-version bump for -lnspr4 follows
> from the simple fact, that it provides new symbols. Things, which don't
> care (gaim, evolution) should have their LIB_DEPENDS cleaned up to not
> insist on a particular version of nspr.
> 
> Browsers (when changed) will need to LIB_DEPEND on:
> 
> 	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.

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.

Joe

> 
> Yours,
> 
> 	-mi
> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20050728/b6ec0d93/attachment.bin


More information about the freebsd-gnome mailing list