I have let myself be convinced that what we need is "library source distribution" (i.e. we leave the distribution of compiled libraries to the tools provided for that purpose by the host operating systems).

From there I got the idea that the key to building a common Ada library distribution infrastructure could be to take GPR files (yes, I know what the G stands for) as the library descriptor. As most Open Source Ada developers probably write GPR files anyway, it may reduce the effort involved in inserting libraries and library updates into a common repository. - When it comes to supporting other compilers, I hope that we either can configure "gprbuild" to support other compilers than the G-one, or that we can generate build scripts for other compilers from the GPR files.

My suggestion is that we use project names (i.e. GPR file names minus extension) as the key to identify libraries (but not their versions).

Client-side we want to be able to run commands like these:

ada-lsd-upload <project name>
ada-lsd-search <tag> ... <tag>
ada-lsd-get <project name>
ada-lsd-refresh

• upload = copy to the common repository.
• search = get a list of matching projects from the repository
• get = fetch a library and its dependencies from the repository
• refresh = update all downloaded libraries to their newest versions (keeping all buildable)

Server-side I expect the uploaded packages to be checked for buildability on all the supported platforms, before they are made available to the users.

Some parts of the client-side tools may have to depend on the host system (which compiler to use, which command to use to query the system package manager about installed packages, etc.).

Uploading

Client-side

1. Find ".gpr" in GPR_PROJECT_PATH.
2. Create an empty ZIP archive.
3. Process the found ".gpr" (see below).
4. Sign the ZIP archive.
5. Upload the ZIP archive and signature as a release of "".

Processing a GPR file:

1. Add the GPR file to the ZIP archive.
2. Add all files found in "Source_Dirs" in the GPR file to the ZIP archive.
3. Add any "README" found in the same directory as the GPR file to the ZIP archive.
4. For all with'ed projects:
   • If it is from an installed package: Ignore it.
   • Otherwise: Find and process the matching GPR file (recursively).

Server-side

1. Receive the ZIP archive and signature.
2. Validate the signature.
3. Generate a release ID (hash the ZIP archive contents or something like that).
4. For each platform:
   1. Iterate through working releases for each dependency (newest releases first):
      1. Launch test system (Docker/AmazonEC/...)
      2. Install the selected versions of the dependencies on the test system.
      3. Install the new upload on the test system.
      4. Build (and test) the new upload on the test system.
         • Pass: Register the release as a working release with the tested set of dependency releases on this platform.
      5. Terminate the test system.
   2. Report if the release was registered as working on this platform to the uploader.

Auto-uploading

It might be possible to implement automated packaging from Bitbucket, GitHub etc. by tracking GPR files there.