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

RESOLVED INVALID

Status

Firefox Build System
General
RESOLVED INVALID
17 years ago
2 months ago

People

(Reporter: Frank Belew, Unassigned)

Tracking

Trunk
Future
All
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
Yes, please!  Same for xpcom.

Updated

17 years ago
QA Contact: bugzilla → ktrina

Updated

17 years ago
Target Milestone: --- → M1

Updated

17 years ago
Target Milestone: M1 → Future
(Reporter)

Comment 2

16 years ago
I believe blizzard already has a patch for this.
Yeah, the patch is in the tree, too.

Comment 4

15 years ago
blizzard: So this bug is resolved if a patch is in the tree?
I mean there's an actual patch file in the tree, not that it's been checked in. :)
Product: Browser → Seamonkey
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.
Assignee: slogan → nobody
Component: Installer → Build Config
Product: Mozilla Application Suite → Core
QA Contact: ktrina → build-config
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?
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID

Comment 8

10 years ago
(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

7 years ago
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.

Updated

2 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.