Laszlo (Laca) Peter writes:
> On Fri, 2006-05-05 at 14:09 -0400, James Carlson wrote:
> > - if it conflicts with objects we deliver or likely will
> > deliver (or, per ARC review, just has an objectionably
> > "generic-looking" name), then rename it as part of the
> > packaging, and provide a link using the original name under
> > /{usr,etc,var}/gnu.
>
> I almost agree with this, but I still don't think we should invent
> new g-prefixed or otherwise renamed executables and certainly no
> shared libs or headers. Other files/directories (data, config, etc)
> would be okay to rename, if necessary, but it would have to be done as
> part of the build and not as part of the packaging, otherwise they
> won't be found.
I don't think it's as bad as that.
Renamed executables serves at least one purpose: it makes it possible
for users to choose to use GNU tools for particular purposes without
'entering' the GNU environment by changing $PATH and without typing
the whole path. "gmake" is easy and is fairly well-known.
Note that I'm not suggesting widespread g-prefixing. We should only
rename when there's a conflict or the expectation of a conflict.
The ambiguity I think we need to remove is the "what is the base
installation directory?" question. The answer should be /usr, not
some amalgam of /usr and /usr/gnu. Having a confused build rule means
that we'll end up with a confused system.
And as for libraries, having symlinks under /usr/gnu/lib actually
causes no problems, at least on Solaris. Users who are in the GNU
environment will set their -L flag to point to /usr/gnu/lib, but the
system will resolve the real path name for the library.
For example, if the user does this:
% cc -L/usr/gnu/lib -lbar -o foo foo.c
and libbar.so in /usr/gnu/lib is actually a symlink to
/usr/bin/libgbar.so, the resulting binary will be linked to the
"libgbar" name, not "libbar."
The rest of it is more rarely a problem and easier to deal with on a
case-by-case basis. I agree that if some open source package by
default would deliver a file system object called "/usr/share/data,"
we'd probably have to do some minor surgery on that package before
integrating it. And of course that surgery would have to be part of
the build process. But I think that'd actually be to the benefit of
this hypothetical package: if the too-generic name causes trouble on
Solaris, it likely causes grief elsewhere as well, so fixes there
should not be objectionable.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
