Add IO::Uncompress::UnXz to dependencies #4011
Conversation
|
Since perl-IO-Compress-Lzma (which provides the module) is not in Leap 15.2 yet, we have to link the Factory package to https://build.opensuse.org/project/show/devel:openQA:Leap:15.2 also. |
That would be great if you could do that! |
|
Ok, I added it: Same for Leap 15.2 and 15.1 |
|
Please see the comments here: https://build.opensuse.org/package/show/devel:openQA:Leap:15.2/perl-IO-Compress-Lzma So IO::Compress::Base is in perl core, but also available as a CPAN module ("dual life"). I don't fully understand why this module is problematic, as there are other dual life modules in Factory. But it looks like this can't be resolved quickly, if at all. So we would have to make this module optional for now. |
|
We're trying to link packages from devel:languages:perl. Stay tuned... |
|
Ok, packages linked. Look into the ticket for the details. OBS seems to be happy now |
|
Hi! waves Other people using openQA here, not just SUSE. Requiring something just because OBS produces images in that format seems like a poor choice. It's not a dependency of openQA, it's a thing used in a specific workflow that uses openQA. This should be a recommendation at best. If there's no implementation of soft dependencies, it should be nothing. edit: seems to me a much more appropriate fix for "confusing behaviour when compression/decompression library for a specific asset unavailable" would be to make that behaviour better, not just hard require every compression/decompression library you arbitrarily decide is important. |
|
Maybe it would be better to make it an optional dependency, indeed. We can also add it as dependency of a meta package like the one we already have for the openSUSE test distribution. |
There was a problem hiding this comment.
Hi! waves Other people using openQA here, not just SUSE.
Requiring something just because OBS produces images in that format seems like a poor choice
@AdamWill That's a good point. Normally we just use the openSUSE package as an example of one Linux distribution showing us what's needed upstream here. In this PR seems we have gone to far requiring what openQA does not really require
|
So how should we go forward with this? Just close it? |
|
Weird how Red Hat specific patches like #4006 get approved, and SUSE specific ones like this one not. |
|
To be fair, #4006 is about compatibility with Mojo < 9 in general and this PR is about supporting XZ in general. Both requirements are not necessarily distribution-specific. |
|
The arguments deciding both are about Red Hat packaging though. That's the stated reason why this PR was blocked. It feels very inconsistent. |
|
how about just one line of "Recommends" in the spec file, like for |
Um. My argument didn't refer to Red Hat at any point. It's perfectly simple: this is not a dependency of openQA. openQA does not need it to function correctly or optimally. It should not be listed as a dependency. |
That would be better, though it still seems like a wrong way to "fix" the problem. Why not just improve openQA's behaviour in general when it's being asked to decompress or compress something, but the necessary module isn't available? That would improve things for any similar case, rather than just working around this specific case. |
Improve how? Like automatically install from CPAN? |
|
Like log the problem and the appropriate resolution correctly. The initial description here says: "If this package is not required, then its availability on the webui is accidental and can cause hard to debug "download" errors like reported in https://progress.opensuse.org/issues/94997" There seem to be two angles there: I'm not quite sure what "its availability on the webui is accidental" means, but if it's "accidental", we can fix that, no? And if it causes "hard to debug "download" errors", we can make those errors easier to debug, no? |
Right, #4010 might solve that already. |
|
So, how should we move forward with this? I don't want to force the addition of another pointless dependency. On the other hand being able to decompress ISOs and HDDs is one of the core functionalities that openQA provides and thus I see a certain legitimacy in it depending on a decompression library. |
|
@dcermak nobody questioned that openQA should be able to decompress what it promises. This is just how to handle dependencies. If it's just for o3 of course we can install it there. For the package I recommend a recommend, see #4011 (comment) |
|
FWIW, when there's something we need installed for Fedora's openQA instances but it's not really a dependency of openQA per se, I put it in the ansible deployment plays we use. How are the SUSE official instances deployed? Could you put it there? Aside from that, yeah, a Recommends: or Suggests: would seem less wrong. |
|
@AdamWill yes, that is what I mean as alternative just providing it for the administrated instances. We use salt for the SUSE internal instance openqa.suse.de |
|
I have rebased this PR and relaxed the dependency to a Recommends
|
|
The CI is now failing as it cannot install |
|
yes |
|
please rebase after #4105 was merged |
The UnXz module is required to decompress .xz files which are commonly created by the kiwi appliance builder on OBS. If this package is not required, then its availability on the webui is accidental and can cause hard to debug "download" errors like reported in https://progress.opensuse.org/issues/94997
Codecov Report
@@ Coverage Diff @@
## master #4011 +/- ##
==========================================
- Coverage 97.79% 97.78% -0.02%
==========================================
Files 371 371
Lines 33118 33118
==========================================
- Hits 32389 32385 -4
- Misses 729 733 +4
Continue to review full report at Codecov.
|
|
no objections here, thanks for considering the feedback. |
The UnXz module is required to decompress .xz files which are commonly created
by the kiwi appliance builder on OBS. If this package is not required, then its
availability on the webui is accidental and can cause hard to debug "download"
errors like reported in https://progress.opensuse.org/issues/94997