Project

General

Profile

coordination #16122

[qe-core][functional][epic] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y

Added by dimstar over 5 years ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
New test
Target version:
SUSE QA - Milestone 31
Start date:
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

This is mainly interesting for textbased installs / minimal installs, where the installation of X is trying to be avoided..

We had two examples in the past:

  • emacs requires libgio which in turn depends on the existence of dbus-launch. dbus-launch was provided only by dbus-1-x11 and required X11 libs. As a result, installing emacs without X-libs was not possible
  • vim has just been reported to be linked to X-libraries (boo#1021043)

The idea is to get a framework / API, that can get a package to install and verify that a list of RPMs is not being pulled in by this.

openQA might be 'too late' - other ideas are welcome


Subtasks


Related issues

Related to openQA Tests - coordination #67456: [functional][u][epic] Add package test for sconsRejected2020-06-09

History

#1 Updated by okurz over 5 years ago

  • Category set to New test
  • Target version set to future

#2 Updated by okurz over 4 years ago

dimstar: How about a OBS based multibuild package test as in https://build.opensuse.org/package/show/home:okurz/python-openqa_review with calls to rpm to check which packages are installed and which not?

#3 Updated by dimstar over 4 years ago

okurz wrote:

dimstar: How about a OBS based multibuild package test as in https://build.opensuse.org/package/show/home:okurz/python-openqa_review with calls to rpm to check which packages are installed and which not?

Might be an option - the main concern of course is if/how anybody will react on the failure and resolve it.

#4 Updated by okurz over 4 years ago

Hm, I think this ticket would belong better in https://progress.opensuse.org/projects/opensuse-release-process but then not more people will see it I assume.

#5 Updated by okurz over 4 years ago

  • Subject changed from Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y to [functional][u] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y

dimstar Given the current description I am sorry that QSF will not be able to work on this ticket but we would be happy to try if you help us understand the requirements better. Could you try to specify more specific "acceptance criteria" for the ticket?

#6 Updated by okurz over 4 years ago

  • Target version changed from future to future

#7 Updated by simotek about 4 years ago

This would also be really useful for creating SLE-16 when the time comes to ensure that patterns are not pulling in packages they shouldn't the SLE releaes managers had to spend alot of time tracking down packages that were being pulled in by patterns when they shouldn't be, adding this api for tumbleweed will ensure we don't have any regressions here. If you look at line 4396 of https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3/patterns-openSUSE/patterns-openSUSE.spec?expand=1 we used to have a minimal_base-conflicts pattern to prevent certain files being installed on a minimal system, this shouldn't be needed as of SLE/Leap 15 but it would be nice to have openQA tests to verify it.

#8 Updated by okurz over 3 years ago

  • Priority changed from Normal to Low

let's focus more on improving our current tests and workflows first. Putting to "holding tank" :)

#9 Updated by szarate over 2 years ago

  • Priority changed from Low to Normal
  • Target version changed from future to Milestone 31

Most likely it could be implemented as a test package in obs? the framework would have to be well thought I guess? maybe with libsolv somewhere? Looking at this for the next milestone

#10 Updated by SLindoMansilla about 2 years ago

#11 Updated by SLindoMansilla about 2 years ago

  • Subject changed from [functional][u] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y to [functional][u][epic] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y
  • Assignee set to SLindoMansilla
  • Sergio will ask Dim* if this is still needed.
  • If needed, Sergio will describe the framework on a higher level of such test in OBS at package build and the ticket will be discussed in a grooming meeting.

#12 Updated by SLindoMansilla about 2 years ago

SLindoMansilla wrote:

  • Sergio will ask Dim* if this is still needed.

There is still nothing in place for this. It is still needed.

The problem with OBS is that the scheduler building the dependency tree for what goes into the VM is ignoring recommends on purpose, so it is not possible to test a real case scenario of recommended dependencies.
I need to clarify with BS team about this before discarding the idea of using OBS to cover this regression.

#13 Updated by SLindoMansilla about 2 years ago

SLindoMansilla wrote:

The problem with OBS is that the scheduler building the dependency tree for what goes into the VM is ignoring recommends on purpose, so it is not possible to test a real case scenario of recommended dependencies.
I need to clarify with BS team about this before discarding the idea of using OBS to cover this regression.

For kiwi there is an option to include recommended (or even suggested)
packages.

#14 Updated by szarate almost 2 years ago

  • Tracker changed from action to coordination

#16 Updated by tjyrinki_suse almost 2 years ago

  • Subject changed from [functional][u][epic] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y to [qe-core][functional][epic] Idea: a test / API that verifies that package X does not pull in (direct or indirect) package Y

#17 Updated by SLindoMansilla over 1 year ago

  • Assignee deleted (SLindoMansilla)

No time to work on this :(

#18 Updated by slo-gin about 1 month ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Also available in: Atom PDF