They could go to extreme and do it the Windows’ way by simply installing everything… 
I use a lot of Linux distributions, but none for developing. Windows is more comfortable to me. It is Ada’s strength that you can develop anywhere you wanted and it will seamlessly work everywhere. Usually I do not even test all the targets and rely on Ada.
I agree the docs are often poor and the lack of installer is painful. About 10 years ago, I made an Arch derivative (‘laceOS’) which consisted of a very simple text based installer (answer 5 simple questions and xfce4 and gnatsudio and all then available, common Ada packages were installed). It was intended to be an easy start Ada dev environment. Final user base was … 2 (including myself 
).
I initially chose Arch since I wanted the latest possible package versions. I’ve recently considered reverting to XUbuntu several times, esp since Alire now makes my Arch AUR Ada packages largely redundant.
How? Either Alire packages everything, which it does not, or runs on top of a target packaging system, automatically rewrapping packages.
So far Alire is unable to package simple components, or at least I have no idea how to do it. BTW, I looked your package of the simple components. It is incorrect because i686 and x86_64 architectures need to switch a lot of sources. ODBC is different on the API level for both. Atomic access to 64-bit units is absent in 32-bit GNAT etc One can do that in PKGBUILD by scripting lsb_release. In Alire? No idea. If I ran the circus, I would generate a gpr-package with variables describing the target and the compiler capabilities. Fedora’s Ada policy has something alike, which is very useful.
I’ve just added description for receiver stub of RCI (remote call interface). Take a look.
Alire generates a project file with the host OS, architecture and distribution. I don’t know what you mean by compiler capabilities, but if it is not supported, an issue could be opened explaining the necessity. If it’s for cross compilation, I’ve seen issue #2067, which contains links to other implemented and still open issues.
abstract project Coap_Spark_Config is
Crate_Version := "0.10.0-dev";
Crate_Name := "coap_spark";
Alire_Host_OS := "linux";
Alire_Host_Arch := "x86_64";
Alire_Host_Distro := "ubuntu";
Which features are implemented, for example. A lot of people try new language features to discover that the compiler does not support them. They could add checks in their projects to prevent end user confusion.
My particular issue is whether the pragma Atomic works on Stream_Element_Offset. If it does not, then if there are gcc atomic primitives available, if not then it falls back to protected objects.
What have the crate name and version to do in this? Why is it named after the crate? Why is it host OS, architecture and distribution? I do not care about these on the host, I do about the target. Otherwise it looks promising.
The purpose is to use this project in the user project to select sources and compiler/linker options.
I saw in another discussion means to prevent Alire from hallucinating, pardon, generating gpr-files. If that works and the project above is still generated, then the only remaining issue to me is automated uploading of releases.