#5967: Enable source repo generation --------------------------+----------------------- Reporter: mizdebsk | Owner: rel-eng@… Type: enhancement | Status: new Milestone: | Component: koji Resolution: | Keywords: meeting Blocked By: | Blocking: --------------------------+-----------------------
Comment (by mizdebsk):
Koschei prioritizes package rebuilds according to changes in build dependency tree. After new repo for f22-build is generated, Koschei has to calculate differences in build deps between previous and newly generated repo, for all packages it tracks.
Koschei generates package build dependency tree using hawkey library, which is also used by DNF. Hawkey works with YUM metadata. In this case metadata for both source and binary packages is needed. Source repo contains the SRPM and info about its build requires, binary repo contains dependency info for all RPMs which may be transitive build deps. For binary repository Koschei simply downloads metadada for f22-build from Koji, but there is no repo for source RPMs, so Koschei has to construct it by itself. To do this it downloads SRPMs from Koji and runs createrepo_c on them.
Current solution works, but it has disadvantages:
* extra storage required for SRPMs (about 46 GiB), * SRPMs have to be transfered from Koji over network, * extra code has to be maintained.
We can keep current solution, but enabling source repo generation for f22-build would make things considerably simpler. Additionally I think such repository could be used in other ways too and as such it would be worth enabling.
One problem mentioned during the meeting was arch-dependant SRPMs (SRPMs which have different contents depending on what architecture they have been built). SRPM contents depend not only on architecture, but a number of other things too. Theoretically spec file can contain line like: {{{ %{lua: if(os.time()%2==0) then print("BuildRequires: foo"); end} }}} which will add BuildRequires semi-randomly. I think that there is no way to properly fix all such cases. If some package has non-deterministic build then it's a problem in that package and we shouldn't try to workaround it.