[m-dev.] Determining which grades an installed Mercury compiler supports

[Zoltan Somogyi]

On Wed, 18 Jul 2018 18:28:48 +0200, Keri Harris <keri at gentoo.org> wrote:
> I've run into a couple of interesting issues in how Mercury determines 
> which grades it supports.

The Mercury compiler can generate code for any of its target languages
without any outside help, so I presume you are talking about how
it determines which grades have their libraries installed in the locations
in which it expects, i.e. how it figures what to report when given
--output-libgrades.
 
> The erlang grade can have problems with this approach since init files 
> can be installed into the mercury/module/erlang directory. In 
> particular, a problem can arise when a 3rd-party library installs an 
> erlang init file, and then Mercury is later reinstalled without support 
> for the erlang grade; these residual 3rd-party init files can confuse 
> Mercury into believing that it still does support the erlang grade. The 
> following sequence of events leads to this:
> 
> * compile and install Mercury package such that grade erlang is installed
>    - /usr/lib/mercury/modules/erlang/mer_std.init is created
> 
> * compile and install mercury_fixed library from mercury/extras/fixed
>    - /usr/lib/mercury/modules/erlang/mercury_fixed.init is created
> 
> * recompile and install Mercury such that grade erlang is no longer 
> installed
>    - /usr/lib/mercury/modules/erlang/ still exists

Why does the package manager allow the installation of something that is
*already* installed, without *uninstalling* first?

From what I can see, if one installation overwrites another, the results
are inherently fragile. Mercury installs are tested *only* in the context of a fresh,
clean install; using any other kind of install will work only by luck. One could
get around this by expending specific engineering effort to design (and later test)
an install scheme that could survive specific kinds of partial installs, but
in Mercury's case (and in most other cases) I don't think this would be
worthwhile.

> I can work around the empty-directory problem easily enough by adding 
> zero-byte files into the empty modules/$grade directories when the 
> mercury compiler is installed. Then uninstalling any other package that 
> also owns the modules/$grade directories won't result in these 
> directories being deleted.

That would fix this particular instance of this problem, but not other instances.
I don't think anything would be guaranted to work short of

- checking that every single file that is supposed to be installed is present,
   and has the expected cryptographic hash, and
- checking that *only* the expected files are present in the install directories.

> Strictly speaking, these issues are more related to bundling Mercury 
> with package manager than being inherent to Mercury itself. But both of 
> these issues make me wonder if there is a more resilient way of 
> determining which grades the compiler supports.

We could bake into the compiler the list of the grades that were configured
to be installed at the time the compiler executable was itself created.
However, that would still be vulnerable to parts of the install directory
being overwritten later.

Zoltan.