Move quagga files from /usr/sfw to /usr [PSARC/2008/038 Self Review]

[James Carlson]

David.Comay at Sun.COM writes:
> > Instead, it's *only* for naming conflicts -- cases where there's a GNU
> > variant of some utility (e.g., tar) where a user would want to have an
> > un-prefixed alternative by setting his path.
> >
> > Furthermore, we have GPL all over the system, not just here, and a lot
> > of it is in /usr/lib.  What could make this one project special?
> 
> 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.

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.

Nor, frankly, do I see what establishing such a ghetto would
accomplish.  If you need one, /usr/sfw is already a mess like that.

> 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.

We've been trying to do away with that problem.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677