Changing Vendors On Update

English Install/Boot/Login
#1

Upon updating, is it common practice to change vendors when packman doesn’t reconcile with openSUSE?

I was going to be patient and wait to see if it balanced as time goes on but if this is unnecessary then I’ll change vendors. Matters not to me.

The following 20 packages are going to be upgraded:
  gstreamer-plugins-base libdca0 libgmic3 libgstallocators-1_0-0 libgstapp-1_0-0 libgstaudio-1_0-0 libgstfft-1_0-0 libgstgl-1_0-0 libgstpbutils-1_0-0 libgstriff-1_0-0 libgstrtp-1_0-0 libgstrtsp-1_0-0
  libgstsdp-1_0-0 libgsttag-1_0-0 libgstvideo-1_0-0 libvo-amrwbenc0 libxml2-2 libxml2-tools openSUSE-release openSUSE-release-appliance-custom

The following product is going to be upgraded:
  openSUSE Tumbleweed  20230902-0 -> 20230904-0

The following 2 packages are going to change vendor:
  libdca0          http://packman.links2linux.de -> openSUSE
  libvo-amrwbenc0  http://packman.links2linux.de -> openSUSE

20 packages to upgrade, 2  to change vendor.
Overall download size: 7.6 MiB. Already cached: 0 B. Download only.
Continue? [y/n/v/...? shows all options] (y):
1 Like
Obsolete package error
#2

You show output, but not the command you used. Please always include that one more line in your copy/paste. It makes understanding what happened so much easier for everyone.

#3

I would wait, because I (and I guess you too) added packman essential repo to get better codecs.
Also you don’t have to update constantly on tumbleweed. I once had to wait a whole month because I wasn’t at home and the PC updated just fine.

#4

As these two packages got removed from packman, it is the right solution to switch the vendor back to openSUSE. The last available package versions at packman were for Leap 15.4.

Please don’t follow advises from other new user that “you don’t have to update constantly”. An up to date system is a more secure system than one white outdated package versions…

2 Likes
#5

My normal way is this:

su - -c 'zypper dup -d'

Today I did this:

su - -c 'zypper dup --allow-vendor-change -d'

The standard way openSUSE told me to do it in the documentation.

What difference does the command make in this context?

I usually only update on Friday at 4pm but I’m slowly retiring so I’ve moved it forward to Thursdays because Friday is now a real life day. It didn’t occur to me to update monthly because Arch ruined me.

Thanks for the input. I was going to knee-jerk and do it, but I wanted to make sure because I’m a bit dim re: openSUSE.

#6

It is a general remark about how to post computer text on these forums. Copy/paste of one more line (and best including the prompt and also the new prompt line at the bottom) gives a lot of information to those who try to help you. And also in this case, seeing what you did will help others to understand what happened. We can not look over your shoulder and are not mind readers. What you post is all we have.

1 Like
#7

Well, I once had an update where mesa wanted to do a vendor change and that completely borked my system. So yes, of course it is more secure to stay up to date, but sometimes these vendor changes can ruin your afternoon. Also, I know this may be impossible to implement, but it would be really cool to see why packages need to change vendor while updating.

#8

A little remark from my side for user who are not used to openSUSE (yet) in terms of how to find out whether you actually need a vendor change because the package got removed from a repo:

run

zypper se -v [packagename]

that shows you which packages are in which repository and whether they are installed or not. Note: there are only your aliases for the repos listed but that’s enough in that case.

if you run zypper se -v libdca0 it should show you just the main (OSS) repo but not packman as source. Which means it’s not there (anymore).

2 Likes
#9

“I’m in the dark here…” (ten points to the person who identifies the quote.)

If you’d like to look over my shoulder, by all means, call me.

#10

Thanks. I’m gradually getting used to Zypper. Time is not on my side, but I’ll get there.

1 Like
#11

I’m completely retired as of 2.5 years ago (software engineer), but I didn’t do it slowly - it happened from one day to the next :+1:

Anyway, I run a -zypper dup- daily. There’s a reason for choosing a rolling release distro. The “once a month” mentality really doesn’t conform to the intended use.

If someone is not interested in updating, at least once a week, then they should choose a distro with a philosophy that matches, such as Leap or MicroOS Kalpa or Aeon.

#12

Every morning I look in the mirror at the moron looking back at me and ask “why are you doing this?”

1 Like
#13

Closing comments:

I updated and changed vendors. I rebooted as I do after every update and my encrypted system (redundant - who doesn’t encrypt these days?) became read only. I panicked. Rebooted again. Read only still. Panicked harder. Rebooted again. I can now write to the drive.

This has shaken my confidence and I’m not even going to bother figuring it out (it happened on my Thinkpad too). Who am I kidding, of course I’m going to try and find the issue - I want to sleep tonight!

#14

Thank you for the tip. :+1:
However, this command does not help me figure out whether to switch vendor for libvo-amrwbenc0, does it?

$ zypper se -v libvo-amrwbenc0
Loading repository data...
Reading installed packages...

S | Name                  | Type    | Version            | Arch   | Repository
--+-----------------------+---------+--------------------+--------+----------------------
v | libvo-amrwbenc0       | package | 0.1.3+5-1.2        | x86_64 | Main Repository (OSS)
    name: libvo-amrwbenc0
i | libvo-amrwbenc0       | package | 0.1.3-1699.1.pm.85 | x86_64 | (System Packages)
    name: libvo-amrwbenc0
  | libvo-amrwbenc0-32bit | package | 0.1.3+5-1.2        | x86_64 | Main Repository (OSS)
    name: libvo-amrwbenc0-32bit
#15

Same thing. No packman repo listed, so it is also discontinued I’d presume.

2 Likes
#16

Of course; now I see it. :+1:

1 Like
#17

System package means often:
installed from an Repo but this Repo does not ship that package anymore.

It can also mean:
Downloaded and installed “by hand” without enabling any Repo.

2 Likes
#18

It was previously supplied from Packman
But is no longer
Because it is also available in openSUSE = the switch you were seeing

#19

As a seasoned user I know zypper does the right thing when configured properly. Some call it blissful childish self-assurance.

However unattended background distribution upgrades work like a charm. I safely ignore trivial issues as the above one:

6700k:~ # ssh erlangen journalctl -q -g libvo-amrwbenc0
Sep 07 16:06:32 erlangen zypper[16852]:   libvo-amrwbenc0
Sep 07 16:06:32 erlangen zypper[16852]: libvo-amrwbenc0
Sep 07 16:06:34 erlangen zypper[16852]: In cache libvo-amrwbenc0-0.1.3+5-1.2.x86_64.rpm (1/1),  78.1 KiB
Sep 07 16:06:34 erlangen [RPM][17752]: erase libvo-amrwbenc0-0.1.3-1699.1.pm.85.x86_64: success
Sep 07 16:06:34 erlangen [RPM][17752]: install libvo-amrwbenc0-0.1.3+5-1.2.x86_64: success
Sep 07 16:06:34 erlangen [RPM][17752]: erase libvo-amrwbenc0-0.1.3-1699.1.pm.85.x86_64: success
Sep 07 16:06:34 erlangen [RPM][17752]: install libvo-amrwbenc0-0.1.3+5-1.2.x86_64: success
Sep 07 16:06:34 erlangen zypper[16852]: (1/1) Installing: libvo-amrwbenc0-0.1.3+5-1.2.x86_64 [...done]
6700k:~ #
#20

There’s been a reliance on Packman in the past, but some changes have happened recently, so if available in native repos (openSuse), best to use those.