Bug 1142975 - rubygem-public_suffix 4.0.0 breaks dependencies of rubygem-addressable
rubygem-public_suffix 4.0.0 breaks dependencies of rubygem-addressable
Status: VERIFIED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Patterns
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Manuel Schnitzer
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-26 08:43 UTC by Dominik Heidler
Modified: 2019-08-19 12:29 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Heidler 2019-07-26 08:43:13 UTC
https://openqa.opensuse.org/tests/990604#step/machinery/4

The dependency rubygem(ruby:2.6.0:public_suffix) is not provided.
Comment 1 Tim Hardeck 2019-07-26 09:21:13 UTC
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.
Comment 2 Dominique Leuenberger 2019-07-26 09:49:27 UTC
(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
Comment 3 Tim Hardeck 2019-07-26 10:38:29 UTC
(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.
Comment 4 Swamp Workflow Management 2019-08-07 12:00:07 UTC
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
Comment 5 Tim Hardeck 2019-08-12 13:07:18 UTC
The issue is fixed now by releasing rubygem-public_suffix-3.1.