This is not a machinery issue.

I think it is not good that updates of packages can be released to Tumbleweed which break already existing packages. This happened a couple of times in the past for Ruby gems.

Anyway Manuel updated the public_suffix gem:
https://build.opensuse.org/package/view_file/openSUSE:Factory/rubygem-public_suffix/rubygem-public_suffix.changes?expand=1

There is no new version of the addressable gem yet released anywhere https://rubygems.org/gems/addressable/versions/2.6.0 so it can not be fixed by upgrading addressable but even then it would be not a machinery issue.

If somebody needs an updated gem which would break existing packages they should split the gem in an old and new version, otherwise the submit request should be canceled.

Please fix the rubygem update process or according tests in Factory, it fells like a dll hell.

(In reply to Tim Hardeck from comment #1)
> This is not a machinery issue.
> 
> I think it is not good that updates of packages can be released to
> Tumbleweed which break already existing packages. This happened a couple of
> times in the past for Ruby gems.

It is the nature of a rolling distro to receive frequent updates - and it's a balancing act to allow breakage vs getting releases at all. In a perfect world, I'd agree, all packages would work at any moment. In reality, we are far away from that - there are currently > 250 failing packages in openSUSE:Factory. 

The only 'guarantee' for non-breaking packages are the ones in the rings. We could increase the priority of machinery into the rings - But that requires buy-in from all the maintainers in the stack below machinery, as all build-deps and runtime-deps need to be raised to rings as well. Depending on the number of packages and the build time of said packages, this can in plus have negative impact on the TW release throughput in general.

In any case: once the issue is fixed, we can discuss these options together

(In reply to Dominique Leuenberger from comment #2)
> (In reply to Tim Hardeck from comment #1)
> > This is not a machinery issue.
> > 
> > I think it is not good that updates of packages can be released to
> > Tumbleweed which break already existing packages. This happened a couple of
> > times in the past for Ruby gems.
> 
> It is the nature of a rolling distro to receive frequent updates - and it's
> a balancing act to allow breakage vs getting releases at all. In a perfect
> world, I'd agree, all packages would work at any moment. In reality, we are
> far away from that - there are currently > 250 failing packages in
> openSUSE:Factory. 
Thanks for the explanation.

Can we not verify for eachsubmit request if there are dependency issues with a bot?
Could we not have a script generating a dependency graph once per Factory release and then we use this data for all new submit requests to see if they break something.

So in this case the gem update would have been only accepted if there was an additional public_suffix rubygem submit for version 3 or if the addressable gem was submitted in a version which can handle the new public_suffix.

> 
> The only 'guarantee' for non-breaking packages are the ones in the rings. We
> could increase the priority of machinery into the rings - But that requires
> buy-in from all the maintainers in the stack below machinery, as all
> build-deps and runtime-deps need to be raised to rings as well. Depending on
> the number of packages and the build time of said packages, this can in plus
> have negative impact on the TW release throughput in general.
No, that is not necessary I think but thank you.

This is an autogenerated message for OBS integration:
This bug (1142975) was mentioned in
https://build.opensuse.org/request/show/721502 Factory / rubygem-public_suffix-3.1

The issue is fixed now by releasing rubygem-public_suffix-3.1.

https://openqa.opensuse.org/tests/1009555#step/machinery/2