Excluding the removal of special package locks

English Install/Boot/Login
1

I came along recurring software dependency management challenges.

:eyes: Example:

Sonne:~ # zypper dup
…
Problem: 2: the installed libqt5-qtwebengine-5.15.17-5.1.x86_64 requires 'libavcodec.so.61(LIBAVCODEC_61.3_SUSE)(64bit)', but this requirement cannot be provided
deleted providers: libavcodec61-7.0.2-1699.3.pm.10.x86_64

 Solution 1: keep obsolete libavcodec61-7.0.2-1699.3.pm.10.x86_64
 Solution 2: remove lock to allow removal of libqt5-qtwebengine-5.15.17-5.1.x86_64
 Solution 3: break libqt5-qtwebengine-5.15.17-5.1.x86_64 by ignoring some of its dependencies
…

Thus I would appreciate that the repetition of such resolution options can be reduced.

  • Can the update tool be configured in the way that the lock should be kept for such a package for a while (without further enquiries)? :thinking:
  • Some components need to be preserved before they are really “obsolete”.
2

Do you open 2 threads when using zypper dup?

Delete all your locks as @hui has written.

3

:thought_balloon: I find it helpful to clarify another software situation separately.
:crystal_ball: How will interests evolve further for mentioned software components?

Do you care for any other solution approaches? :thinking:

4

The question in the other thread was a dependency error from the same zypper dup in this thread.

Do you not understand your Problem?

Your Problem is locking packages in an Rolling Release.
Nobody knows Why, but if you need older packages, install Leap.

Now remove all locks and solve the dependencies.

5

Would you like to clarify use cases better also for package locks?

I am using a known program functionality.

Do any more users and system administrators fiddle with package locks occasionally?

This software distribution probably contains also some questionable dependencies.

6

@elfring Please stop this waste of time and energy of others. Consider this a warning

2 Likes
7

This software distribution probably contains also some questionable dependencies.

If you want a highly configurable Linux, maybe slackware or lfs is an alternative.

2 Likes
8

I adjusted my package selection and corresponding settings once more.

Sonne:~ # zypper locks

# | Name                                      | Type    | Repository | Comment
--+-------------------------------------------+---------+------------+--------
1 | nvidia-open-driver-G06-signed-kmp-default | package | (any)      | 
2 | vlc-beta-debuginfo                        | package | (any)      | 
3 | vlc-beta-debugsource                      | package | (any)      |

:crystal_ball: Can the clarification of desirable software behaviour be continued?

9

Is
zypper dup
now working?

10

Yes (in principle according to the current development status of this software tool).

11

So now it is confirmed that there wasn‘t any dependency issue on openSUSE package side.

You locked random packages and broke package dependencies. Each zypper dup the well developed zypper solver asked you: hey you broke dependencies, what to do now?

Instead of surpressing the zypper solver (as you intented to do), you should answer the solver questions as they are made to bring back your system into a consistant state.

And you should learn that locking random packages without actual knowledge of the dependencies on a rolling release is a bad idea unless you have high experience.

1 Like
12

I got other views.
:thought_balloon: It seems that there are further adjustment possibilities which you do not like to take also into account so far.

13

Here you can look inside the Code of zypper and add, what you want.

I think all is said.

1 Like
14

Not yet. :thinking:

15

From me, yes

16

Please could you elaborate on this in more detail?

How exactly should zypper (the solver) react when it finds that there are more than one (in the case you presented in post #1 exactly three) solution to handle a dependency?

1 Like
17

:eyes: Related information sources can trigger further ideas:

I suggest to take another detailed look at corresponding case distinctions.

  1. Would you like to exclude the option “ignoring some of its dependencies”?
  2. Packages can be marked as “Protected ‒ Do not modify”.
    Can such a setting indicate that would not like to be bothered with the enquiry “remove lock to allow …”?
  3. Would you be willing to keep any software packages which became “obsolete” because of special circumstances?

:thought_balloon: Another idea:

  • Can any packages be connected with management groups?
  • How do you think about the support for solution policies?

:crystal_ball: Software evolution:
Precision of package requirement specifications

18

I personally would not like this option to be excluded. There have been occasions when I had to “break” a package dependency explicitly.

You don’t want zypper to offer “ignore dependencies” nor “remove lock” so the only two choices left would be

  1. keep the old package
  2. cancel the installation process

I assume option 2. is not really what you are looking for and as to option 1.

what is supposed to happen to packages which rely on a newer version (of that “obsolete” package)?

Sorry, but I do not understand what you mean by “management groups” and “solution policies”. Could you explain this in more detail please?

And please be aware: I’m no developer. If you want to address developers this forum might not be the place to do this.

19

One could get the feeling that this is an extremely sophisticated form of trolling. This feeling is reinforced by the fact that this user has already received several lifetime bans in various developer mailing lists and forums. Spam of the same questions over and over again, ignoring valid answers, not answering questions at all, wasting developers’ time. Maybe it’s time again…

20

Or extremely sophisticated bot.