* Dave Miner ([email protected]) wrote: > On 07/20/10 02:03 PM, Glenn Lagasse wrote: > >* Dave Miner ([email protected]) wrote: > >>On 07/19/10 04:28 PM, Glenn Lagasse wrote: > >>>* Glenn Lagasse ([email protected]) wrote: > >>> > >>>>>install-beadm.mf: > >>>>> > >>>>>Do we really want a compilation link for libbe in /usr/lib? > >>>> > >>>>Probably not. This was part of the original manifest and has been > >>>>delivered to the system all this time so I didn't think to change it. > >>>>I'll double check, but I can't think of any reason we need to deliver it > >>>>and so if that's true I'll remove it (or follow up with what I find if > >>>>it's not true). > >>> > >>>And as it turns out, we do in fact need this. The link allows us to > >>>version the library without having to change the target that people link > >>>against. All of the ON libs (at least the portion that I reviewed) do > >>>this and I couldn't find any sort of mechanism to deliver the library > >>>itself (lib.so.x) and not the link (lib.so) (which is probably why we > >>>delivered it this way in the first place). > >> > >>Yes, that's what's always done in the proto area. > >> > >>>I spoke with Evan and he > >>>couldn't remember all the reasons why but remembered the part about the > >>>versioning. So, I'm inclined to leave it unless someone knows how to > >>>just deliver the library file itself and not the link in both the proto > >>>area and manifest (the manifest part is of course easy, but nightly > >>>complains if you have objects in your proto area and not in a manifest > >>>and vice-versa). > >>> > >> > >>Common practice for project- and consolidation-private interfaces is > >>to deliver the symlink in the proto area but not in the packaging. > >>There are numerous examples of this (from networking, libipadm, > >>libinetsvc are but two). I don't recall what extra machinery is > >>involved with this, but it's well-trod ground. > > > >Alright, I've worked out how to make this happen and so that's what I'll > >do. We'll create the symlink in the proto area as we do now but we > >won't deliver it to the system. While I'm at it, do we need to deliver > >the lint libraries to the system? The manifest currently includes them: > > > >file path=usr/lib/llib-lbe > >file path=usr/lib/llib-lbe.ln > > > > No, we shouldn't deliver them in the package, for the same reason - > it's not a public interface.
That's what I thought. They're out of the pool as well then. Thanks Dave. Glenn _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
