sclorg
Create .repo with dependent repositories
In case of dependencies between repositories, users have to find and enable each dependent repository. In case of passenger40 it means to enable 7 different repositories.
It would be great to generate .repo with all the dependent repositories, so user could download/enable just single .repo which would later enable all the dependencies.
OK, but we need to specify it more precisely. Should such .repo be part of the RPM we already have or shell I add another RPM? If I add new repos, it may lead to collisions (if two or more collections depend on the same one).
How about to sym-link the RPMs containing .repo files of dependencies to the current repository? User would download the RPM with repo file for passenger40 (the one we already have) and then it would be possible to use YUM to install the other necessary repos. In case that the user already have some of those repos installed, there would be no collision. The user may even decide to take dependencies from any other repo.
I've actually had a similar idea about depended repositories on my mind already some time, but I'd rather build it in copr directly, because it is the place where we define repositories available for dependencies etc. In the end we could create one repository with all SCL collections, which would be more similar how RHSCL works.
So, my idea was to be able to specify depended coprs and create a new bigger repo from all packages in all depended coprs + packages in this particular copr. Then we do not need to specify a repository for depended packages, it would be done automatically and correctly for all buildroots.
As for the implementation, I guess hardlinks are what we would need here, since symlinks could break when package disappears from depended repo and the new repo is not re-generated yet. The re-generation itself might get tricky as well, since we might do it automatically or manually, both has advantages and disadvantages at the same time.
Would not be better to have command which would care about it? Like"
scl repo enable ruby193
which would comunicate via API to softwarecollection.org or even Copr?
I don't think moving this functionality to scl is a good idea, since this is a general copr issue, not strictly connected to scl.
We may rather reconsider the goal of existance a 'depended repo field' -- from my POV it implements a feature of "building a copr above some other copr". Which makes great sense to me, but we should implement it properly also in the usage-time part, not only in the build-time part.
We use an RPM package to enable the SCL repository, right?
What if we put those RPMs into another repository ("of repositories") and make the RPMs dependent on each other?
User would install the main "repository of repositories" in their system. Than they would install a repo of desired collection with yum/dnf - which would also installed all other repos needed. And they are ready to use!
