Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Mikael Djurfeldt <address@hidden> writes:

>> For Debian at least I was packaging things for now so that you can
>> only have one guile-X.Y-dev package installed at a time.  To do
>> anything different would require more upstream changes (including the
>> above), and until/unless that happens, people should be able to get by
>> by just switching out the -dev packages.
>
> Are you sure, considering what I wrote above?

Yes (depending on what you mean) because the -dev package on a Debian
system is the one that contains the .so links, so it dictates which
library you'll get when you say -lfoo if there's more than one
candidate available.

It won't help with your /usr/lib vs /usr/local/lib problem, though.
Putting the major number in the library name is how you'd have to fix
that.

Note that if you wanted (as you suggested above) to allow two micro
revisions to be installed in parallel for debugging, we'd have to go
so far as to put the full version into the library name,
i.e. libguile-12.0.1.so or similar, and I would argue fairly strongly
against that.  With the full version in the library name, all apps
compiled against guile would have to be recompiled when we make *any*
guile release, even just a micro revision.  It's possible you could
avoid that with symlink tricks or similar, but I'd be much more
comfortable, if we do anything, with just putting the soname in the
library name, and not planning to support parallel installs of micro
revisions.

Of course I don't actually have a good answer, other than "remove the
.so symlinks" (i.e. the -dev pkg on a debian system) to the question
of how on any given platform you can actually test/develop a minor
guile revision that's different from the one in /usr/lib when you also
have to use other foo-config tools that might insert -L/usr/lib into
random places on the gcc command line, but this is not a problem
specific to guile.  It's a broader foo-config/unix-model problem.

pkg-config may be able to help here, and gcc could fix the problem if
it supported --push-flags and --pop-flags args, but AFAIK neither fix
is available yet.  We might be able to solve this problem by putting
all our libs into /usr/lib/guile/VERSION/ so that you have to specify
a -L flag to get anything, but then you've got the ld.so.conf problem,
and I agree with Marius that we're probably better off sticking with
the normal unix mechanisms and perhaps trying to help come up with a
better answer "upstream" if possible.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu