Bug 1079541 - Wrong rpm-requires in yast2-storage-ng package
Wrong rpm-requires in yast2-storage-ng package
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: Christopher Hofmann
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-02-06 10:22 UTC by Markus Elfring
Modified: 2019-04-15 12:15 UTC (History)
2 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 Markus Elfring 2018-02-06 10:22:13 UTC
Yesterday I updated some software components once more.

These versions are installed at the moment:
* yast2 4.0.49-1.1
* ruby 2.5.0-2.2


A message box presents the following error information for an execution try of the command “yast2 sw_single”.

“…
Details: Failed to load Module 'Packages' due to: Failed to load Module 'SpaceCalculation' due to: cannot load such a file -- storage
Caller: /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59 in `require'”
Comment 1 Christopher Hofmann 2018-02-07 16:30:32 UTC
Looks like you missed to update parts of YaST and its dependencies.

Please use `zypper verify` to check if all package dependencies are satisfied.

Are they?
Comment 2 Markus Elfring 2018-02-07 16:48:03 UTC
(In reply to Christopher Hofmann from comment #1)
> Are they?

Yes.

Which RPM specification should trigger the software installation for the ruby module “SpaceCalculation”?
How should related software extensions be kept consistent in this use case?
Comment 3 Christopher Hofmann 2018-02-07 17:11:40 UTC
Which versions of
 yast2-packager
and 
 yast2-storage-ng
are installed?
Comment 4 Markus Elfring 2018-02-07 17:20:03 UTC
(In reply to Christopher Hofmann from comment #3)

yast2-packager 4.0.35-1.1
yast2-storage-ng 4.0.82-1.1
Comment 5 Christopher Hofmann 2018-02-07 17:43:17 UTC
`zypper up libstorage-ng1` will solve your problem.

We need to fix the requirements, here:
rpm -q --requires yast2-storage-ng
libstorage-ng-ruby >= 3.3.45
(…)

While:
# rpm -q libstorage-ng-ruby libstorage-ng1
libstorage-ng-ruby-3.3.145-1.1.x86_64
libstorage-ng1-3.3.145-1.1.x86_64
Comment 6 Christopher Hofmann 2018-02-07 17:59:27 UTC
Fixed in git. Review awaited.
https://github.com/yast/yast-storage-ng/pull/513
Comment 7 Markus Elfring 2018-02-07 18:06:05 UTC
(In reply to Christopher Hofmann from comment #5)
> libstorage-ng-ruby-3.3.145-1.1.x86_64
> libstorage-ng1-3.3.145-1.1.x86_64

I can acknowledge that the command “yast2 sw_single” is working again also in my software installation.
Should the openQA system detect any version mismatches here?
Comment 8 Christopher Hofmann 2018-02-12 09:34:14 UTC
(In reply to Markus Elfring from comment #7)
> (In reply to Christopher Hofmann from comment #5)
> > libstorage-ng-ruby-3.3.145-1.1.x86_64
> > libstorage-ng1-3.3.145-1.1.x86_64
> 
> I can acknowledge that the command “yast2 sw_single” is working again also
> in my software installation.
> Should the openQA system detect any version mismatches here?

That situation can only happen when updating only parts of an existing installation. There is a test suite testing full TW-updates using `zypper dup`:
https://openqa.opensuse.org/tests/607130
Going that way libstorage should have been updated anyway - even with that too-weak rpm requirement.

Did you use `zypper dup` for updating your whole system? Or did you maybe just update parts of it using `zypper up <package>`?
Comment 9 Markus Elfring 2018-02-12 17:54:14 UTC
(In reply to Christopher Hofmann from comment #8)
> That situation can only happen when updating only parts of an existing installation.

Why?

Should RPM specifications should usually ensure that relevant versions should generally fit together for all required software components?


> Did you use `zypper dup` for updating your whole system?

No.


> Or did you maybe just update parts of it using `zypper up <package>`?

Yes.


Another attempt for a current distribution upgrade suggests a dependency resolution like the following.

…
  postgresql10                            obs://build.opensuse.org/server:database -> openSUSE                       
…
  xfce4-session                           obs://build.opensuse.org/X11 -> openSUSE                                   
…
  xorg-x11-server                         obs://build.opensuse.org/X11 -> openSUSE                                   
…
  xxdiff-tools                            obs://build.opensuse.org/devel:tools -> obs://build.opensuse.org/X11       
…
1676 packages to upgrade, 843 to downgrade, 352 new, 5 to reinstall, 810 to remove, 830  to change vendor, 2 to change arch.
Overall download size: 2.72 GiB. Already cached: 0 B. After the operation, 2.0 GiB will be freed.
…


My selection of priorities is special for the involved installation sources.
Comment 10 Christopher Hofmann 2018-02-13 10:20:08 UTC
(In reply to Markus Elfring from comment #9)
> (In reply to Christopher Hofmann from comment #8)
> > That situation can only happen when updating only parts of an existing installation.
> 
> Why?
> 
> Should RPM specifications should usually ensure that relevant versions
> should generally fit together for all required software components?

Of course. So we changed the obviously wrong "Requires" in the spec to fix that.

This just wanted to answer your question about covering this by an openQA test.

And this answer can only be: We have a test, that covers the only supported way to update TW. Unfortunately this problem does not occur using this way to update. A test only updating parts of the distri is not feasible, because this is a moving target (as TW is).

The fixed package made it to OBS. Installing yast2-storage-ng >= 4.0.91 does it right.
Comment 11 Markus Elfring 2018-02-13 15:37:12 UTC
(In reply to Christopher Hofmann from comment #10)
> So we changed the obviously wrong "Requires" in the spec to fix that.

Thanks for your quick software update.

I am curious if a similar adjustment will be needed again for corresponding (Ruby) modules.


> Unfortunately this problem does not occur using this way to update.

Will there any extensions be appropriate for the test methodology?