Dne 11. 01. 21 v 15:15 Stephen Gallagher napsal(a):
On Mon, Jan 11, 2021 at 5:55 AM Vít Ondruch <vondruch(a)redhat.com
<mailto:vondruch@redhat.com>> wrote:
Can the ELN be fixed to stop doing rebuild like this? Of course
the issue is not in rubygem-thin but the issue is that once the
Ruby side tag was merged, ELN did not bothered with build order
and now there is rubygem-eventmachine which was built against Ruby
2.7 where is should have been build against Ruby 3.0. I can't
rebuild it, because that would require release bump in Fedora (I
don't want to do that, because Fedora maintainers should not be
bothered with ELN, right?).
I think that ELN should try to follow the Rawhide build order. If
it can't do that, then it should wait for manual intervention.
This is on our todo list, but we have been balancing a lot of things
at the same time and haven't been able to get to it yet. Believe me,
we want this fixed ASAP because it causes us (the ELN maintainers) a
lot of problems.
I think that ELN should have done gating or scratch build and
check if the dependencies are the same as in Rawhide or something.
I'm not sure where or when in the process you are suggesting this
would happen. ELN gates the compose, but not the builds.
When ELN built rubygem-eventmachine, it should have make sure that the
dependencies are as expected. If rubygem-eventmachine depends in Rawhide
on libruby.so.3.0()(64bit), then the dependency on
libruby.so.2.7()(64bit) should trigger alarm.
Also, rubygem-eventmachine should be installable after rebuild. But
certainly, there might happen race conditions a it happened this time.
I think that ELN should check the build result for dependency
issue and stop blindly submitting builds.
Again, I'm not sure what you're asking for, here.
For a human, single rebuild and check of log for rubygem-thin would
reveal that something is wrong with rubygem-eventmachine. This could be
detected from root.log and flagged. More builds are not needed.
Vít