Closed Bug 107654 Opened 20 years ago Closed 13 years ago

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

Categories

(Firefox Build System :: General, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID
Future

People

(Reporter: frb, Unassigned)

Details

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.
QA Contact: bugzilla → ktrina
Target Milestone: --- → M1
Target Milestone: M1 → Future
I believe blizzard already has a patch for this.
Yeah, the patch is in the tree, too.
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
Closed: 13 years ago
Resolution: --- → INVALID
(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.
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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.