On Wed, 25 Jun 2008, Nelson B Bolyard wrote: >> That sounds great. Of course there's no need to do anything "LSB", you >> could just at this very moment establish a subdir (called say "nss") that >> you use for your public headers and make sure that's the way all distros >> would use. > > We don't have much control over what the downstream distros do to (with) > NSS. Getting them to all do something the same way has been compared to > herding cats. That's one reason we're pursuing LSB. The distros DO seem to > want to do things the same way when the LSB says to do that.
Right, but if you would install your public headers in [prefix]/include/nss for example and that is what 'make install' does, and your pkg-config stuff (or whatever you provide) would _not_ do -I/usr/include/nss but assume that that applications would #include <nss/header.h> you would take a signigicant step towards herding the cats in the right direction. If you would do it, I don't see why any distro would not folllow. Distros that currently have taken a route that differs from that could easily just symlink (or similar) their way back to compliance. In my eyes, LSB is far too big and too much of a risk to just stall somewhere to be something to wait for. Besides, once you've decided how you think the CORRECT way is, all of us users can then go out and whine on our distros to follow the upstream suggested way of working these matters. >> The current flux is terrible for apps trying to use NSS. > > I'd be open to receiving any more specific information about specific > problems in specific distros. The NSS team members just don't spend much > time trying out all the different distros that use NSS, so we haven't > collected much info about specific issues with specific distros. This specific problem in Debian vs Fedora: Debian: /usr/include/nss Fedora: /usr/include/nss3 Debian's "pkg-config --cflags nss" returns -I/usr/include/nss -I/usr/include/nspr My configure script can detect NSS fine on both these systems. It can detect how to build my app with NSS. But I cannot include <nss/base64.h> since I would need to do it #include <base64.h> and thus it collides with other headers named "base64.h". In my case I have a private header using that name. In fact we also had a header called nss.h but we renamed that due to this problem. >> Did you ever try to build the 3.12 from the tarball? > > Yeah, it depends on another product, NSPR, whose tarball is also available > from ftp.mozilla.org, and which is also supplied in many distros. Right, I've been told that now but it certainly was not clear to me when I picked a download. I just wanted to build NSS. >> First I of course strongly dislike that there's no install/build >> instructions in the tarball, > > Yeah, it would be good to put a readme in the tarball that at least points > to the web site where all the docs are. I would prefer the build instructions to be bundled with the package I download, as plain text. A README or INSTALL that's easily found. >> then I dislike that I have to chase around in subdirs of the package to >> figure out where to build and then when I invoke what I think is the >> correct build line: > > There is a nice web page with detailed instructions on how to build NSS and > NSPR, including how to get the tools if you don't have them (e.g. shell-like > tools for Windows). We expect that people will look on mozilla.org for any > docs. The tarball could say that, but doesn't. Right, and that's what parts of my complaint is about. I find the web site hard to navigate and get info from and including this info in the tarballs is normally done by open source products. By not doing this, you decide to act differently than the majority and I can't see any benefits from it. The "least-surprise" principle is generally good imo. I'll admit that I'm inpatient, but I also consider myself an experienced *nix and open source developer and I know (or thought I knew) exactly what I'm looking for. >> * docs ([...] using it, APIs etc) > > On the web sites > www.mozilla.org > wiki.mozilla.org > developer.mozilla.org > all searchable with google, et. al. First, this is still my opinion. You listing some URLs don't change this. Second, I want man pages for all functions my app uses or is likely to use. Third, to test your claim picked a random NSS function from libcurl's lib/nss.c file. I googled for "SSL_CipherPrefSet" to get to read your docs for it. I think it proves my point pretty good: I can't find any official NSS docs for it using google. Possibly one reason why this is hard is that on the NSS pages you tend to create very large html pages listing a vast amount of functions on each page. > Actually, all the docs cited above are exactly about building and using NSS > stand-alone, by itself, not as part of the browser. The API documentation > cited above is all about NSS's own direct API, not about the C++ wrappers > that are part of the browser. Right, but the site still suffers badly from the Mozilla connection since the left-side and top menus are all mostly (all?) non-NSS related links so it makes it hard to navigate to find all the NSS goodies. Example: view the NSS "home page" at http://www.mozilla.org/projects/security/pki/nss/ And then "get source", "hacking", "built it" or whatever in the left-side menu will take you to... something that certainly isn't about NSS. Or rather, it will take me to an application that uses and bundles NSS. Certainly not what I am interested in atm. -- / daniel.haxx.se _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
