>> It's my understanding that those GPL components under /usr/lib should >> not be there per the most recent guidelines from Sun legal. So it was >> my recommendation to the team to explore the alternative of >> /usr/gnu/lib as Quagga is one of the GNU components in the FSF/UNESCO >> Free Software Directory. > > Something's going awry here, as a "closed approved automatic" case > should not be the place for Sun's legal group to set new architectural > policy for the system.
Something tells me that we're no longer in "closed approved automatic" land, Toto. :-) This isn't a new architectural policy per-se but a restatement of the existing policy that we've been working under. Or at least that I've been working under. :-) And I realize that this policy hasn't been articulated outside of Sun which is something we've been working to change as part of a revised set of GPL/LGPL architectural guidelines that we want to make available soon. I'd love for us to be able to liberalize the policy in the namespace area as part of that effort. > I know of no practical reason to segregate GNU bits into a special > ghetto. Just about all of GNOME is under GPLv2 or LGPL, and we > intentionally don't do any separation with those, and I don't see why > Quagga is being subjected to a different set of rules. Note that as far as I know, there isn't as much of a concern about LGPL components for obvious reasons. > Nor, frankly, do I see what establishing such a ghetto would > accomplish. If you need one, /usr/sfw is already a mess like that. Believe me, I don't want to segregate these bits either - remember, I'm on this kick to make things familiar. But as with readline case, there was/is the concern about delivering viral libraries under /usr/lib. Or do you see a difference between this case and the one for readline? >> Upon rereading PSARC 2007/047 though, you're correct that it's focused >> on the naming conflict instead of other sorts of conflicts. Assuming >> these libraries are Project Private (note that the opinion for the >> Quagga case, PSARC 2005/57, is missing so I'm not sure of the stability >> level here), would a reasonable solution here be to instead deliver >> those components under /usr/lib/quagga? Private? > > No. I want to see them in /usr/lib, or a clear explanation of why > they can't be there. As best I can tell, they belong there just as > much as any of the GNOME bits. > > The reason I think it's important is that Quagga offers interfaces for > new protocols to be built on top. Hiding these libraries in a > non-standard location just makes us different from other platforms for > no reason, and sets us up for the same kind of mess that /usr/sfw > created. So these libraries do deliver public interfaces and the creation of new protocols can be done outside of the Quagga project? > We've been trying to do away with that problem. Again, you won't get any pushback from me on this in the general case. If /usr/lib is where everyone else delivers the libraries, then that's what I'd like to see at some point. But from a practical point of view, I do see a difference between a library exporting public interfaces and those which implement project implementation details. dsc
