On 5/9/24 7:48 AM, Darryl Gregorash wrote:

On 2024-05-08 15:33, cagsm wrote:

...

Support,

some simple current 15.5 when zypper dup to 15.6 i get this questionaire, but i can not really decide what to do? when selecting one or the other removal of obsolete libopenssl-1-1-1-devel or other is called libopenssl-devel-1-1-1 doesnt really help.

weird naming? maybe the one or other originates even from leap 15.4 level?

thanks for helping on this how to decide:

--------------------------------- Problem: 1: the to be installed libopenssl-1_1-devel-1.1.1w-150600.2.16.x86_64 conflicts with 'libopenssl-devel > 1.1.1w' provided by the to be installed libopenssl-devel-3.1.4-150600.2.1.noarch Solution 1: Following actions will be done: keep obsolete libopenssl-1_1-devel-1.1.1l-150500.17.25.1.x86_64 keep obsolete libopenssl1_1-1.1.1l-150500.17.25.1.x86_64 keep obsolete libopenssl-devel-1.1.1l-150400.1.5.noarch keep obsolete openssl-1.1.1l-150400.1.5.noarch keep obsolete openssl-1_1-1.1.1l-150500.17.25.1.x86_64 Solution 2: deinstallation of libopenssl-1_1-devel-1.1.1l-150500.17.25.1.x86_64 Solution 3: deinstallation of libopenssl-devel-1.1.1l-150400.1.5.noarch -------------

the solution 2 or 3 no matter which only asks for more removal of other python stuff thereafter.

the only simple stuff would seem solution 1, keep old stuff? can I delete them thereafter once inside 15.6? how do I search for obsoleted or orphaned rpm packages?

thank you all.

libopenssl-devel-3.1.4 is going to be installed. A check in YaST/Software manager shows that it obsoletes the two packages you currently have installed on your system. (Why you have packages for both Leap 15.4 and 15.5 on your system is a mystery.)

This is usually common for SLE based packages in Leap, given that we don't do a full rebuild for each service pack. Although the fact you have an openssl-devel package that doesn't match your openssl package is incorrect and probably leading to the issues here. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 09.05.2024 11:21, cagsm wrote:

is this some RC bug just yet?

devel packages usually provide the same files so it is simply impossible to have several versions concurrently. zypper also cannot know which version you are developing against so it cannot decide for you.

On Thu, May 9, 2024 at 1:35 PM cagsm wrote:

okay sorry, this is just a very simple machine, i am not developing anything. also i am unaware of ever having to have installed any devel packages? just wanted to upgrade a machine from 15.5 to 15.6 rc, this machine probably came from 15.4 earlier and even older releases before that i guess. but pretty sure its always been only very simple normal use cases kde desktop and nothing fancy at all.

okay anyhow thanks for all the feedback, I really dont understand where all these packages come from but now I have, still being inside 15.5, issued some zypper rm commands to clear up those asked for obsoleted? packages: ----- sudo zypper rm libopenssl-devel-1.1.1l-150400.1.5.noarch sudo zypper rm python-dbus-python-common-devel-1.2.16-6.3.1.x86_64 sudo zypper rm python3-dbus-python-devel-1.2.16-6.3.1.x86_64 ------ after this, a zypper dup to 15.6 doesnt ask any questions any more except for it to start the actual upgrade. thanks all.

Darryl Gregorash wrote:

I had a suspicion you would sooner or later be saying this. The most likely reason you have all these development packages installed is because they were recommended by something else. They got installed because your zypper configuration allows installation of recommended packages. To stop this, (as root) load /etc/zypp/zypp.conf into your favourite editor, and find "solver.onlyRequires". Most likely it is set to "false". Change that to "true" (without the quotes) and save the file.

As a packager for a few openSUSE packages, I die a little inside whenever I see anyone recommend this, frankly reckless (I do not mean it with malice towards anyone, but it just is), configuration to not-so-experienced users. Long-ish rant follows — please humour me — but TL;DR: You should only set no-recommends as the default zypp behaviour **if and only if** you fully understand what its implications are and what `Requires`, `Recommends`, `Supplements`, and especially `Supplements: (pkgA and pkgB)` in an RPM specfile convey. You are guaranteed to miss out on important features that the packager — who works on the package and really understands what additional features its 'Recommends' provides — intends the default user to benefit from. Please consider the following examples (from Tumbleweed, but they apply to ANY distro, not even limited to openSUSE): * There is a package called 'nautilus-extension-owncloud' in Tumbleweed. The `Supplements: (owncloud-client and nautilus)` in the package's specfile means that if you have the nautilus file manager installed in your system (perhaps you are a GNOME user, where it is there by default) and install owncloud-client, the package nautilus-extension-owncloud will be automatically pulled into your system to provide integration with the nautilus file manager. What does it do? Well without it, nautilus will not show sync status or context-aware menus for your sync folder even though you have owncloud-client running. Is it strictly required? Of course, not. Does it add value to owncloud-client and nautilus? To the regular, it absolutely does! Would you know why openSUSE does not provide those nice file-manager icons to integrate owncloud-client into your file-manager that DistroX does right away, if you indeed turned off recommended packages by default? If the answer to that is 'Yes, of course! I always check to see package "FOO-extension-BAR" is installed if I need FOO's integration with BAR!', go ahead and reconfigure the default. * Perhaps in the above case you might say, anyone would just know to install `nextcloud-extension-owncloud` if they wanted file-manager integration, it is right there in the name! I would say, first, thank you for acknowledging that the packager — I — chose a sensible name for the package LOL. Sometimes, though it may not be so obvious. Consider the case where you have a recent (top-of-the-line or not!) CPU in your machine. You install openSUSE TW on it and immediately turn off recommended packages for zypper. Would you know that you would be missing out on those nice AVX/AVX2 enhanced libraries that make every dependent package simply take off in terms of speed and performance? These are installed as RECOMMENDED packages when openSUSE detects that your machine is capable enough to handle these so-called x86-64-v3 enhanced instructions. Turn off recommended packages, would ever know that for every performance impacting `libz1`, there is a `libz1-x86-64-v3` that could make your machine roar where it would otherwise merely purr? If the answer to that is "Of course, I would not even be using Linux if I did not know about x86-64-v3 hwcaps!", by all means go ahead and re-configure to turn off default package recommendations. Otherwise, please take a pause to consider the implications. A default is the default for good reason. A packager spends time understanding what a package requires, what packages it should recommend for a default user, and what other packages it should merely suggest. You are choosing to override this, if you change the default behaviour — which you are certainly free to do, but make sure that you understand what that means, before you do. Also, if you find a package with spurious (in your opinion) recommends, please open a bug report. We always appreciate reviewing and fixing issues like these and then the fix helps everyone. For example, a non-devel package should never, typically, require/recommend a -devel package. If you know that one did, opening a bug report against the package in question will make the packager review the Recommends list of their package. Wishing everyone a nice weekend and thanks for dredging out time from yours to read my rant-ish rambling all the way to its end (or wherever I lost you!). -- Atri

Darryl Gregorash wrote:

On 2024-05-11 06:06, Atri Bhattacharya wrote:

...

Darryl Gregorash wrote: I had a suspicion you would sooner or later be saying this. The most likely reason you have all these development packages installed is because they were recommended by something else. They got installed because your zypper configuration allows installation of recommended packages. To stop this, (as root) load /etc/zypp/zypp.conf into your favourite editor, and find "solver.onlyRequires". Most likely it is set to "false". Change that to "true" (without the quotes) and save the file. As a packager for a few openSUSE packages, I die a little inside whenever I see anyone recommend this, frankly reckless (I do not mean it with malice towards anyone, but it just is), configuration to not-so-experienced users. Long-ish rant follows — please humour me — but TL;DR: You should only set no-recommends as the default zypp behaviour **if and only if** you fully understand what its implications are and what `Requires`, `Recommends`, `Supplements`, and especially `Supplements: (pkgA and pkgB)` in an RPM specfile convey. You are guaranteed to miss out on important features that the packager — who works on the package and really understands what additional features its 'Recommends' provides — intends the default user to benefit from. Please consider the following examples (from Tumbleweed, but they apply to ANY distro, not even limited to openSUSE): Thanks for your comments; they are very informative, and welcome.

Sincerely appreciate your read-through and feedback.

I do have only one observation: If a package adds important features that users will find beneficial, or even nearly essential, to supplement the features they want on their systems, then perhaps the package should be a "require", not a "recommend".

No, requires are those packages without which a package would manifestly break. In the first example, not having the file-manager integration icons and context menu does not break anything existing in the system. Both the file-manager and owncloud-client perform fine regardless, you simply do not get the feature that the integration package provides. Furthermore, an experienced user may actually not want this integration, so making them Recommends allows them to uninstall the package without breaking any behaviour. A requires would not allow its removal without also removing owncloud-client itself. In the 2nd case, requires would not work. It would force the package to be installed on a -v3 supporting hardware, so, for instance — and among other things, you would not be able to remove them to benchmark how the base non-v3 packages perform for comparison. The main decision as to whether a pkg should be required or recommmended is typically made on the basis of the following question: if an experienced user, say, for reasons related to having a minimal system, were to remove a package, would it break any functionality of the packages left installed in the system? Of course its removal would kill certain features — there is no 'no-op' package — but would it leave anything broken? If yes, then require it, if not, then recommend it. Hope that helps. Cheers, -- Atri

Felix Miata wrote:

Atri Bhattacharya composed on 2024-05-11 13:58 (UTC-0000):

...

requires are those packages without which a package would manifestly break.

This is only theoretical WRT openSUSE package maintainers. Several believe broken "theme" is manifest breakage.

Felix, My response was in the context of the question whether it is a good idea for regular users to disable the installation of recommended packages. Your point, whilst being worth a discussion, is not directly related to the thread in my opinion. With that said, let me suggest that human packagers can have disagreements with human users and other human packagers¹ about the lines where Recommends become Requires (but never vice versa!). Indeed, there are times I have disagreed with other packagers/users about similar issues without really reaching an agreement. A minority of such line-splitting issues do not make the entire question of Requires vs Recommends moot, I would posit. Thanks for your response. ¹At least until AI takes over packaging completely and we can build DistroX with minimal human intervention ☺️ Cheers, -- Atri

On 2024-05-09 02:21, cagsm wrote:

On Thu, May 9, 2024 at 12:18 AM Darryl Gregorash wrote:

...

libopenssl-devel-3.1.4 is going to be installed. A check in YaST/Software manager shows that it obsoletes the two packages you currently have installed on your system. (Why you have packages for both Leap 15.4 and 15.5 on your system is a mystery.) You can choose either option 2 or option 3. I expect, no matter which one you do choose, you will then immediately be faced with the question of whether or not to remove the other one -- and you should also choose the option to remove for that one.

can I just use option one keep all the stuff (it apparently doesnt confuse other stuff or doesnt state any problems with option one, does it?) and later remove the stuff? how do I filtere obsoleted packages? obsolete means nothing except itself is provided by a package and nothing else needs a package? is this the meaning of being obsolete?

I had a nagging sensation that this sort of thing was going to happen if you kept doing this with zypper. I should have directed you to YaST in the first place. Run YaST/Software Manager, and search for libopenssl-devel Find the package with version 3.1.4-150600.2.1 If that package is not installed, click on the box to select it for installation. Click on "Accept" and let YaST do its thing. You will most likely be faced with conflicts. Always select the choice that will keep version 3.1.4. Keep doing this until all conflicts have been resolved.

is this some RC bug just yet? how to get a cleaned up and good situation here? I havent seen this in trials of installing RC via dup on sone other machine thank you.

No, it is not a bug.

On 2024-05-09 05:53, cagsm wrote:

i can zypper dup to 15.6 now just fine after having removed those pesky devel stuff, see my mail to this thread before. thanks.

OK, thanks for letting us know. Do be sure to make that change to /etc/zypp/zypp.conf in the earlier email, to make sure this sort of thing doesn't happen again.