107654 - nspr and nss libraries should have their own categories in the packages-unix file

Status: RESOLVED INVALID

Description

[Frank Belew]

Multiple programs now, including evolution and mutt, use the NSS libraries for
SSL connections and cert db services. As it stands, the current packages-unix
bundles nspr with xpcom and that into the browser itself. This causes the
programs to depend on an entire mozilla browser installation in order to get SSL
capabilities.

Comment 1

[Christopher Blizzard (:blizzard)]

Yes, please!  Same for xpcom.

Comment 2

[Frank Belew]

I believe blizzard already has a patch for this.

Comment 3

[Christopher Blizzard (:blizzard)]

Yeah, the patch is in the tree, too.

Comment 4

[Alexander Opitz]

blizzard: So this bug is resolved if a patch is in the tree?

Comment 5

[Christopher Blizzard (:blizzard)]

I mean there's an actual patch file in the tree, not that it's been checked in. :)

Comment 6

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

I think this bug doesn't belong with SeaMonkey... Apart from that, I'm not sure I found the right spot to triage it, nor even if it is still valid.

Comment 7

[Ted Mielczarek [:ted.mielczarek]]

Blizzard: correct me if I'm wrong here, but plenty of programs are using system NSPR/NSS, and they don't depend on Mozilla packaging at all, correct?

Comment 8

[Alexander Sack]

(In reply to comment #7)
> Blizzard: correct me if I'm wrong here, but plenty of programs are using system
> NSPR/NSS, and they don't depend on Mozilla packaging at all, correct?
>

yes, distros should package those on their own and most major distros do so for quite some time already.

Comment 9

[JVD]

Yes, but what if, like me, users don't want to install a distro ?

Why must the mozilla build system rely on distro maintainer hacks
to reliably install the system libnspr (usually in /usr/include/nspr +
/usr/lib{,64?}/nspr ) and system nss3 (/usr/include/nss + /usr/lib{,32,64}/nss )
( or for that matter, if libxul SDK install is selected, /usr/include/xul/ + 
/usr/lib{,32,64}/{,xul?}/libxul* ) ?

Particularly when software far more basic and crucial (such as gcc + gcj ) packages as well as the packages discussed here (sorry folks - no offence
to "blizzard") - depend on the correct installation of Mozilla NSPR + NSS + xulrunner ? 

Also, once a complete nspr + nss + libxul + xulrunner build has been built
in $MOZ_OBJDIR/dist and installed on the host system, a complete firefox build with (--with-system-xul-sdk=) takes @ 5 minutes as opposed to @ 5 hours .

Wouldn't it be nicer for the firefox build to be able to rely on the
installed NSPR + NSS + XUL SDK instead of insisting on rebuilding everything
from scratch, IF they are of the correct version ?

I think this bug raises some important issues and ought to remain open - I 
am actually working on a fix for it and will attach this bug report to 
the bug I raise to submit the patch.