Kerl fails to install previous builds if kernel upgraded

[jadeallenx]

This is due to the otp_release script looking in the wrong directory for a makefile. The error message kerl give you is terrible - it says "failed to install" but there's no reason for the failure.

So we should try to make this failure more clear to the end user and one way of doing that is to check to see if the kernel has been upgraded versus when the build was done. We could put the uname -r output into our build metadata file and check that for example.

[paulo-ferraz-oliveira]

@jadeallenx, if this still happens I'd like to understand it to potentially fix it. If it doesn't, maybe we can consider closing it (?). Wanna give me a brief list of steps so I can understand what triggered the issue? (I do understand it's been 6+ years, but maybe your words speak more to you than to me 😄)

[paulo-ferraz-oliveira]

Ah, even without understanding it all, I think I can protect the install by what you mention in the last sentence.

I'll need to find that metadata file and update it, much like we do with the activation script, these days.

I'll start with a sentence like

WARNING: this Erlang/OTP build appears to be stale. It was created with
         kernel release    '...' while currently your system's
         kernel release is '...'."
         You should consider removing the build with `kerl delete build ...` and
         re-installing it with `kerl build-install ...`"

[jadeallenx]

IIRC on macOS when you went from X to X+1 it broke all of my Erlang builds and it was kind of a silent failure until you attempted to reuse it. As far a repro - it would be something like, build Erlang on macOS N-1, and then try ot activate it and build some Erlang app on macOS N

[paulo-ferraz-oliveira]

Ok. And in that case would a message be enough, as proposed? Or do you want to try some 🪄?

[paulo-ferraz-oliveira]

This is where we set the metadata: .kerl_config:

    TMPOPT="${TMP_DIR}/kerloptions.$$"
    echo "${CFLAGS:-}" >"$TMPOPT"
    echo "$KERL_CONFIGURE_OPTIONS" >>"$TMPOPT"

We seem to be doing nothing with the contents except comparing MD5 to understand if re-configuring is required.

As-is, though, the content is unreadable (unless you read kerl's source).

Would it be acceptable to put more info. in the file for context?

e.g.

This is kerl's control file for build configuration.
CFLAGS: ...
KERL_CONFIGURE_OPTIONS: ...
uname -r: ...

It would also allow the script to parse the contents.

[jadeallenx]

Would it be acceptable to put more info. in the file for context?

Sounds like a plan

[jadeallenx]

Ok. And in that case would a message be enough, as proposed? Or do you want to try some 🪄?

I think a message is enough - not sure this happens all that frequently tbh

[paulo-ferraz-oliveira]

Yeah, it'll just be an extra control, so hopefully easy to implement, too.