Scripts are not portable

1. Usage of #!/bin/bash instead of #!/usr/bin/env bash
   1.1. why are the script using bash in first place, instead of pure /bin/sh? it is bit more work but keeps the script portable.
2. lsb_release is not portable to all Linux based systems, e.g. Alpine Linux.
3. Usage of sudo, if I am the root and there is no other user (e.g. typical docker environment), then the fails: ./configure: line 1729: sudo: not found

Haven't reached too far when trying to build against musl-libc based Alpine Linux.

[JumpingYang001]

In fact, not all PowerShell supported plarforms officially support by omi, you can check what platforms we officailly support in README, also check some reasons here: #456 , thanks.

Thanks. I think there are two aspects of it: package/binary distribution from official channel and the other is build from source.
Binary distribution is mostly not required on the downstream consumer repository as there is a build tool chain dependency already present and we can compile dependency code.
However, this issue is about building from source.

• POSIX complaint native unix Bourne shell script
• Usage of potable way to get distribution information, e.g. https://unix.stackexchange.com/a/6348
• avoiding the usage of sudo inside the script (caller must run the main buildscript as sudo if necessary)

Adapting some of these portable, yet future-proof, approaches will unblock building on many kinds of Unix like operating systems, regardless of which operating systems' binary packaging is officially provisioned.

[JumpingYang001]

For sudo issue, just try "apk add --no-cache sudo".
but ./configure is just the first step, and there are 9999 steps after that. :)

Alpine Linux is just one example, but why should we care which(ever) Unix? :)
IMO, the issue really is the usage of sudo in the script, instead of main build/configure scripts simply requiring sudo at the invocation time. If I am the root, then running sudo will give me error that root doesn't belong to sudoer group.

Build docs can state something like:

Prerequisites:

• libpam0g-dev
• libssl-dev
• perl
  etc.

Usage:

Note that OMI build requires super user privileges:

sudo ./configure

etc.

By marking the dependencies as prerequisite, we can remove all the usages of yum, apt-get, sudo etc. from the scripts themselves. This way, given any Unix with the dependencies installed, the product will build without us scanning and autocorrecting missing dependency situation at build time. If we really to ease up build on RHEL, Ubuntu etc. we can provide a bootstrap-ubuntu.sh, bootstrap-rhel.sh etc. extracting out the dependencies installation lines; which IMHO is not necessary and listing in docs is enough for devs.

TL;DR, if we can achieve the same by not avoiding <os>-<distro>-<version>-specific stuff, lets agree on that. Implementation can gradually improve things without breaking any officially supported OS and giving room to other "not officially supported Unices".

[JumpingYang001]

Sounds good.

[palladia]

At this point we don't have the resources to make enhancements.

[mi-hol]

If MSFT wants to be perceived as supporting open source seriously
'Adapting some of these portable, yet future-proof, approaches will unblock building on many kinds of Unix like operating systems, regardless of which operating systems' binary packaging is officially provisioned.' is from my view mandatory!

May I kindly ask to reviewed this with your manager for strategy internally?

[mi-hol]

@SteveL-MSFT isn't this valid (but simply closed!) issue making your life as pwsh leader harder then necessary too?

[SteveL-MSFT]

@mi-hol I think we need to pick our battles as I don't have a large team. I do know that dotnet team is planning on leveraging PSCore6 for all their build/deploy scripts going forward (exception being .NET Core itself which has lots of native dependencies) that build with dotnetcli.