Build: Build script won't run on "unsupported" operating system

[moondeck]

I've tried to compile Armbian on my Deepin machine, and the script complained about it not being supported, and the build script didn't start. How about instead of stopping the script, display a big ol' message like "You are running a unsupported host system, this is not recommended or supported by us, your mileage may vary. If you encounter any bugs/something doesn't work, do not report it."

A quick change in lib/general.sh to make it display a warning instead of exit with error made the script work just fine for me. I could submit it as a pull request, or perhaps, you don't like that kind of solution, a mechanism to detect a debian-based distro could be implemented?

[zador-blood-stained]

How about instead of stopping the script, display a big ol' message like "You are running a unsupported host system, this is not recommended or supported by us, your mileage may vary. If you encounter any bugs/something doesn't work, do not report it."

We had this kind of message originally, but people demanded answers/fixes/improvements for untested environments and didn't want to hear that we don't care about issues on anything other than Xenial x86_64. This was the final straw and I'm pretty sure that this behavior won't be reverted - you can fix software but not people who don't want to read or understand non-critical warnings.

a mechanism to detect a debian-based distro could be implemented?

Detecting a Debian-based distro is not enough as the build script relies on default compiler versions for some targets, relies on availability of some packages (and having new enough versions of those packages) and availability of some tools that may not be present on all Debian based systems (like systemd-nspawn).

[moondeck]

Thanks for the fast answer, i understand, i actually thought this might be an issue. How about something like a environment variable, that would allow that if set? Pretty idiot-proof (you gotta be somewhat experienced with Linux to know how to set and use environment variables) and easy to implement, possibly with a single "if-else" in general.sh. Let me know what you think about it, i would like to implement that.

[zador-blood-stained]

How about something like a environment variable, that would allow that if set?

I'm not against a hidden (not mentioned anywhere) variable, and if there are no objections from @igorpecovnik and @ThomasKaiser it can be implemented, though we have to remove Trusty support workarounds first.

[moondeck]

I am afraid i cannot help with the Trusty workarounds, as i have no machine running Ubuntu, but as mentioned, i am willing to do the variable "thing". Do you have a To-Do list for the script (or for Armbian in general), or something like that?

[igorpecovnik]

If there is some variable documented only in the code, I don't mind.

[moondeck]

Great, i shall implement that then and then make a PR.

[ThomasKaiser]

Quoting myself:

Besides that we recommend a virtualized environment for OS images for
a single reason (not mentionend anywhere yet except forum): If there's
ever just a little error when dealing with image creation (happens as
root using dd and trying to overwrite sectors of the image) the build
system can overwrite your whole OS or at least renders it unbootable!

The main reason people like to use something else than Ubuntu 16.04 is
that they already run something else that's Ubuntu-ish. And that's bad
and should be avoided. So forcing users to setup an own virtual
machine wit 16.04 is already fighting lazyness and preventing a mess
if something ever goes wrong.

In other words: of course it's a weird idea to allow this now.

[moondeck]

So, basically, you are saying that running anything other than ubuntu is bad or what? I see the point with virtualization though, but i think allowing people to override it IF they know what they're doing is a good thing.

[zador-blood-stained]

So, basically, you are saying that running anything other than ubuntu is bad or what?

First, that running natively (without a container or VM) is bad when you apply heavy customization to the build script (example, read the last message for the resolution) and when you are not ready to accept side effects and unintended consequences (i.e. user's ccache dir owned by root, additional sources.list, added i386 dpkg arch, etc.). And therefore allowing to run on untested environments (at least without setting undocumented variables) is bad because it doesn't force the user to use containers or virtualization.

And second, adding hacks or workarounds for different build environments is just a waste of time when we have a working environment that can be quickly and safely deployed i.e. with Docker.