Project

General

Profile

Actions

coordination #16122

open

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

Added by dimstar about 7 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Spike/Research
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:
Sprint:
QE-Core: April Sprint 23 (Apr 05 - May 03)

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 1 (0 open1 closed)

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

Actions
Actions #1

Updated by okurz about 7 years ago

  • Category set to New test
  • Target version set to future
Actions #2

Updated by okurz about 6 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?

Actions #3

Updated by dimstar about 6 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.

Actions #4

Updated by okurz almost 6 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.

Actions #5

Updated by okurz almost 6 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?

Actions #6

Updated by okurz almost 6 years ago

  • Target version changed from future to future
Actions #7

Updated by simotek almost 6 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.

Actions #8

Updated by okurz about 5 years ago

  • Priority changed from Normal to Low

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

Actions #9

Updated by szarate about 4 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

Actions #10

Updated by SLindoMansilla over 3 years ago

Actions #11

Updated by SLindoMansilla over 3 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.
Actions #12

Updated by SLindoMansilla over 3 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.

Actions #13

Updated by SLindoMansilla over 3 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.

Actions #14

Updated by szarate over 3 years ago

  • Tracker changed from action to coordination
Actions #16

Updated by tjyrinki_suse over 3 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
Actions #17

Updated by SLindoMansilla about 3 years ago

  • Assignee deleted (SLindoMansilla)

No time to work on this :(

Actions #18

Updated by slo-gin over 1 year 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.

Actions #19

Updated by dimstar over 1 year ago

I think a rather 'simple' solution we could try would be something like:

sub ensure_pkg_A_does_not_pull_pkg_B() {
mkdir /tmp/PKGA_chroot
zypper -r /tmp/PKGA_chroot ar http://openqa.opensuse.org/··location/of/our/repo
zypper -r /tmp/PKGA_chroot in PKG_A
return (zypper -r /tmp/PKGA_chroot info PKGB | grep "Installed:.*No")
}

Actions #20

Updated by szarate about 1 year ago

  • Tags set to qe-core-april-sprint
  • Status changed from New to Workable
  • Target version changed from Milestone 31 to QE-Core: Ready
Actions #21

Updated by szarate about 1 year ago

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

Let's discuss this deeper during the planning, keeping in mind that openQA might be too late; where else could we do this? #note-19 looks like a great starting point, what tool do we have to perform queries to? (thinking that I'd also like to know for instance, who is the bugowner of x package, smelt? another web app? )

Actions #22

Updated by szarate about 1 year ago

  • Tags changed from qe-core-april-sprint to qe-core-april-sprint, platform-team
Actions #23

Updated by szarate about 1 year ago

  • Sprint set to QE-Core: April Sprint 23 (Apr 05 - May 03)
Actions

Also available in: Atom PDF