On Wed, 3 Sep 2008, Alan DuBoff wrote: > That's correct, it passes the location when configure is run.
Yeah, OpenSSL is fairly easy to get working. >> GSSAPI takes some hacking on build files. LDAP takes a bit more hacking. > > Yes, I started to talk to Mike Sullivan about this issue, some...but we > didn't get into too many details... Well, their build system is pretty weird. They've migrated to using autoconf, but not automake (least, not for the GSSAPI related stuff). They have their own way to auto-generate some build stuff. It gets very twisty. I know how to hack it to build, but you have to actually build twice, and edit some auto-generated in between. :( I think it'd be cleaner to just rewrite their makefiles in automake, but that suggestion didn't seem to go down well on the alpine list. Though, getting alpine in with just SSL support would be better than no alpine at all.. > The notion is similar to the Companion CD, Blastwave, sunfreeware, > pkgsrc, etc...and that is that in the big picture, you need to build > and ensure that your packages all work together. In the case of the > Companion CD that was in /opt/sfw, /usr/pkg for pkgsrc, or /opt/csw > for Blastwave. > > My belief is that we need to be one and the same always. The path question is an ARC issue and is, I believe, settled. It goes in /usr/bin. Unless you're philosophing about open-source generally on OpenSolaris? That's a tricky one, but it would indeed be nice to have a common infrastructure for packages... > Given that OpenSolaris seems to be moving in that direction, to locate > all within /usr, packages should be required to use system libraries > which are already available, and supply any additional packages > needed, for putback. Well, there's two things here: a) What a package should deliver to the system (files, dependencies) b) How we put packages together Slightly different, but still impacting each other. For the former we have the ARC. For the latter we need to build up a good collection of packages. To do that requires an iterative process of identifying and reducing (if not eliminating) any sources of drag on contributors, e.g.: - minimising the need to know about Sun-internal bailiwicks (e.g. 'contrib' CDs versus SFWnv) - organising the infrastructure so that, as far as a contributor is concerned, the system is geared towards building their individual package Speaking as a maintainer of a package in SFW, I think it fails pretty badly on the latter point (least it did earlier in the year, and I doubt it's changed ;) ). > There could be another notion that would require sfwnv to be separate > from /usr, and I would like to hear if so, to understand that > perspective. Has the ARC changed its mind this year and reversed its stance established in various cases in years prior? Either way, the reasoning is in the ARC archives. ;) regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150
