Guile's DATAROOTDIR and DATADIR

Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

"./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/).

Is there a potential problem here?

TIA

Re: Guile's DATAROOTDIR and DATADIR

[Mark H Weaver]

Eli Zaretskii <eliz@gnu.org> 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

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: guile-devel@gnu.org
> Date: Fri, 15 Jul 2016 13:25:46 -0400
> 
> 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?

It make sense if it indeed works in practice.  You seem to say there
are in fact ABI incompatibilities in the 2.0.x series, and if that's
indeed true, then the only way to avoid trouble is to rebuild and
reinstall all the packages that are linked against Guile, once I
install the latest Guile.  That is unfortunate, to say the least,
since Guile is already used in important GNU packages such as GDB and
Make.

Is it possible to publish the list of ABI incompatibilities between
2.0.11 and 2.0.12 specifically?

Thanks.

Re: Guile's DATAROOTDIR and DATADIR

[Mark H Weaver]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark H Weaver <mhw@netris.org>
>> Cc: guile-devel@gnu.org
>> Date: Fri, 15 Jul 2016 13:25:46 -0400
>> 
>> 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.

Sorry, my statement above was in error.  It was based on a false claim
made by David Kastrup here:

  http://article.gmane.org/gmane.emacs.devel/174438

He wrote that our NEWS file "lists plenty of things that have been
_removed_ during the stable-2.0 branch, breaking existing uses", but the
examples he cited were *deprecations*, not removals.  Existing uses
continue to work throughout the 2.0.x series.

I spent some time searching our NEWS file for examples of *actual* ABI
breakage in 2.0.x, and I didn't find anything.

>> 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?
>
> It make sense if it indeed works in practice.

As I wrote in my previous message, it does indeed seem to work in
practice, based on the lack of bug reports indicating otherwise.  If you
have evidence to the contrary, please bring it to our attention.

> Is it possible to publish the list of ABI incompatibilities between
> 2.0.11 and 2.0.12 specifically?

I'm not aware of any.

     Mark

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 04:39:24 -0400
> 
> > It make sense if it indeed works in practice.
> 
> As I wrote in my previous message, it does indeed seem to work in
> practice, based on the lack of bug reports indicating otherwise.  If you
> have evidence to the contrary, please bring it to our attention.
> 
> > Is it possible to publish the list of ABI incompatibilities between
> > 2.0.11 and 2.0.12 specifically?
> 
> I'm not aware of any.

Great, this means the problem doesn't exist.  Thanks.

Re: Guile's DATAROOTDIR and DATADIR

[Andy Wingo]

On Fri 15 Jul 2016 19:46, Eli Zaretskii <eliz@gnu.org> writes:

> Is it possible to publish the list of ABI incompatibilities between
> 2.0.11 and 2.0.12 specifically?

Any incompatible change between 2.0.12 and a previous release in the
2.0.x series is a bug.  It is impossible to make a list of all bugs in a
project of course :)

I do not know of any incompatibility introduced in 2.0.12.

Andy

Re: Guile's DATAROOTDIR and DATADIR

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: Mark H Weaver <mhw@netris.org>,  guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 11:06:06 +0200
> 
> Any incompatible change between 2.0.12 and a previous release in the
> 2.0.x series is a bug.  It is impossible to make a list of all bugs in a
> project of course :)
> 
> I do not know of any incompatibility introduced in 2.0.12.

Thanks, that's good to hear.