Hello, A few weeks ago, I asked about techniques for making new packages available to other new packages so that the autopkgtest job could be run successfully in a pipeline in the Salsa CI environment. Eventually, this was made to work by taking advantage of the aptly job defined in the standard Debian CI pipeline.
To recap, the aptly job publishes the package built during the execution of a pipeline by creating a dedicated apt-compatible package repository just for that package. Such repositories can then be made available to various jobs in the pipeline of another package, allowing the successful installation of that package and its dependencies, including new packages, and the successful execution of jobs like autopkgtest. However, one other thing I wanted to achieve was to take the complete set of new packages and to publish them in a single package repository. This would allow people to install and test the built packages in a more convenient fashion than asking them to hunt down each built package from job artefacts or to build the packages themselves. Obviously, the aptly job in the standard Debian CI pipeline publishes a single package (or maybe a collection of packages built from a single source package), but I wanted to aggregate all packages published by a collection of aptly repositories. Fortunately, it seems that this is possible by augmenting the existing aptly job definition as shown in the following file: https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa-ci.yml Ignoring the "ls" command which was there to troubleshoot this rather opaque environment, one script adds repository definitions to the apt configuration, whereas the other performs the appropriate "apt source" and "apt download" commands, making the source and binary package files available for aptly to process. Consequently, aptly will include all the dependency packages in the final package repository. (Since the scripts reside in my package's debian directory, I also had to request the availability of the Git repository for the job. Generally, I have found it challenging to have these job definitions make effective use of scripts due to environmental inconsistencies.) I imagine that publishing packages like this is not particularly desirable, at least if done widely, but I hope it shows that it can be done relatively easily, at least if all the right incantations have been discovered. Paul