Re: Guile's DATAROOTDIR and DATADIR

[Mark H Weaver]

Eli Zaretskii <address@hidden> writes:

> "./configure --help" says:
>
>  Fine tuning of the installation directories:
>    [...]
>    --datarootdir=DIR       read-only arch.-independent data root 
> [PREFIX/share]
>    --datadir=DIR           read-only architecture-independent data 
> [DATAROOTDIR]
>
> AFAIU, this means PREFIX/share/guile/2.0/ is where the *.scm files
> will be installed.  That is, installing Guile 2.0.12 will overwrite
> the Scheme files that were installed there by previous Guile 2.0.x
> versions.
>
> If the above is true, then the question that bothers me is whether
> replacing these files might cause any trouble for programs that were
> compiled against previous Guile 2.0.x versions (like GDB and Make, for
> example).  If there are potential incompatibilities visible on the
> Scheme level, then I think a versioned directory under
> PREFIX/share/guile/2.0/ would be in order, so that several versions of
> Guile could live on the same system.
>
> The same issue arises with the cache directory, where the *.go files
> are installed (I have those in LIBDIR/guile/2.0/ccache/).

We are aware of these potential issues, which is why we must be careful
to ensure ABI compatibility within a stable release series, e.g. within
2.0.x.  If we accidentally break something that uses Guile within a
stable series, that's a bug.

In practice, we seem to be doing a good job of ensuring ABI
compatibility within 2.0.x, based on the lack of bug reports of this
nature.  I don't recall seeing reports of upgrades within 2.0.x causing
breakage, outside of simple bugs.

Having said this, I will admit that we've not maintained perfect ABI
compatibility within 2.0.x, e.g. we've removed some obscure interfaces
that were intended to be kept private, or were broken and could not be
easily fixed, and that we believed to be unused in practice.  This is
not ideal, and I think we will need to be much more strict about this in
the future, as Guile becomes more widely used.

In any case, to the extent that there's a problem here, the solution is
to redouble our efforts to avoid ABI breakage.  The solution is most
definitely *not* to have separate directories for every maintenance
release.  The reason is that we want existing Guile programs compiled
against 2.0.11 to benefit from the bug fixes in 2.0.12.

Does that make sense?

       Mark