Changes in gstreamer bad/ugly provided by Packman
Greetings all Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past. In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now). This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change. Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be: gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs (and depending on 32-bit or not) gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit /Bjørn
Hi Bjørn, On Sat, 29 Jan 2022, 12:16:40 +0100, Bjørn Lie wrote:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Thanks for providing this change! I just did the upgrade and found some obstacles which others might see, too: $ zypper dup --allow-vendor-change ... This resulted in several messages about file conflicts. Reason is that the gstreamer-plugins-bad-orig-addon and gstreamer-plugins-ugly-orig-addon packages remained installed, but they should go away - perhaps there is an Obsoletes: missing in the new packages. Also gstreamer-plugins-bad-codecs did not get automatically installed while gstreamer-plugins-ugly-codecs did. So the proper sequence might be the following to work around the small issues: $ rpm -e gstreamer-plugins-bad-orig-addon gstreamer-plugins-ugly-orig-addon $ zypper dup --allow-vendor-change $ zypper in gstreamer-plugins-bad-codecs
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
/Bjørn
HTH, cheers. l8er manfred
lø., jan. 29 2022 at kl. 12.50 +0100 +0100 skrev Manfred Hollstein <mhollstein@t-online.de> følgende:
Hi Bjørn,
On Sat, 29 Jan 2022, 12:16:40 +0100, Bjørn Lie wrote:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Thanks for providing this change! I just did the upgrade and found some obstacles which others might see, too:
$ zypper dup --allow-vendor-change ...
This resulted in several messages about file conflicts. Reason is that the gstreamer-plugins-bad-orig-addon and gstreamer-plugins-ugly-orig-addon packages remained installed, but they should go away - perhaps there is an Obsoletes: missing in the new packages. Also gstreamer-plugins-bad-codecs did not get automatically installed while gstreamer-plugins-ugly-codecs did.
So the proper sequence might be the following to work around the small issues:
$ rpm -e gstreamer-plugins-bad-orig-addon gstreamer-plugins-ugly-orig-addon $ zypper dup --allow-vendor-change $ zypper in gstreamer-plugins-bad-codecs
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
/Bjørn
HTH, cheers.
l8er manfred
Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version} Provides/Obsoletes is in place, but I should have used Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon without the version check ... /Bjørn
I also added the missing supplements in gstreamer-plugins-bad-codecs, so that too should now get automagically installed. lø., jan. 29 2022 at kl. 12.56 +0100 +0100 skrev Bjørn Lie <bjorn.lie@gmail.com> følgende:
lø., jan. 29 2022 at kl. 12.50 +0100 +0100 skrev Manfred Hollstein <mhollstein@t-online.de> følgende:
Hi Bjørn,
On Sat, 29 Jan 2022, 12:16:40 +0100, Bjørn Lie wrote:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Thanks for providing this change! I just did the upgrade and found some obstacles which others might see, too:
$ zypper dup --allow-vendor-change ...
This resulted in several messages about file conflicts. Reason is that the gstreamer-plugins-bad-orig-addon and gstreamer-plugins-ugly-orig-addon packages remained installed, but they should go away - perhaps there is an Obsoletes: missing in the new packages. Also gstreamer-plugins-bad-codecs did not get automatically installed while gstreamer-plugins-ugly-codecs did.
So the proper sequence might be the following to work around the small issues:
$ rpm -e gstreamer-plugins-bad-orig-addon gstreamer-plugins-ugly-orig-addon $ zypper dup --allow-vendor-change $ zypper in gstreamer-plugins-bad-codecs
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
/Bjørn
HTH, cheers.
l8er manfred
Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version}
Provides/Obsoletes is in place, but I should have used
Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon
without the version check ...
/Bjørn
On Sat, Jan 29, 2022 at 6:57 AM Bjørn Lie <bjorn.lie@gmail.com> wrote:
lø., jan. 29 2022 at kl. 12.50 +0100 +0100 skrev Manfred Hollstein <mhollstein@t-online.de> følgende:
Hi Bjørn,
On Sat, 29 Jan 2022, 12:16:40 +0100, Bjørn Lie wrote:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Thanks for providing this change! I just did the upgrade and found some obstacles which others might see, too:
$ zypper dup --allow-vendor-change ...
This resulted in several messages about file conflicts. Reason is that the gstreamer-plugins-bad-orig-addon and gstreamer-plugins-ugly-orig-addon packages remained installed, but they should go away - perhaps there is an Obsoletes: missing in the new packages. Also gstreamer-plugins-bad-codecs did not get automatically installed while gstreamer-plugins-ugly-codecs did.
So the proper sequence might be the following to work around the small issues:
$ rpm -e gstreamer-plugins-bad-orig-addon gstreamer-plugins-ugly-orig-addon $ zypper dup --allow-vendor-change $ zypper in gstreamer-plugins-bad-codecs
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
/Bjørn
HTH, cheers.
l8er manfred
Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version}
Provides/Obsoletes is in place, but I should have used
Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon
without the version check ...
It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same. Basically, never use "%{version}" for this case, always use "%{version}-%{release}". -- 真実はいつも一つ！/ Always, there's only one truth!
lø., jan. 29 2022 at kl. 07.16 -0500 -0500 skrev Neal Gompa <ngompa13@gmail.com> følgende:
It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same.
Basically, never use "%{version}" for this case, always use "%{version}-%{release}".
Noted for future ref, for now I went with the versionless Obsolete all past, present and future versions of orig-addon, granted that might come back and bite me in the behind should we ever want to reintroduce orig-addons for bad/ugly. /Bjørn
On Sat, Jan 29, 2022 at 7:43 AM Bjørn Lie <bjorn.lie@gmail.com> wrote:
lø., jan. 29 2022 at kl. 07.16 -0500 -0500 skrev Neal Gompa <ngompa13@gmail.com> følgende:
It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same.
Basically, never use "%{version}" for this case, always use "%{version}-%{release}".
Noted for future ref, for now I went with the versionless Obsolete all past, present and future versions of orig-addon, granted that might come back and bite me in the behind should we ever want to reintroduce orig-addons for bad/ugly.
As a general point, the only case where you should use "%{version}" instead of "%{version}-%{release}" for Requires is when the package is *not* from the same source package. For Conflicts/Obsoletes/Provides, you should basically *always* use "%{version}-%{release}" instead of "%{version}" because of this and many other cases where the latter fails to do the right thing. Tons of openSUSE packages do the wrong thing here and I know that it has caused issues in the past with upgrades, even if people haven't necessarily figured it out because understanding debugsolver output is *hard*. I figured it out a while ago as part of bringing DNF into openSUSE and debugging all the failure modes for big upgrades with Zypper that I've experienced over the years. -- 真実はいつも一つ！/ Always, there's only one truth!
Hello, Am Samstag, 29. Januar 2022, 13:16:43 CET schrieb Neal Gompa:
On Sat, Jan 29, 2022 at 6:57 AM Bjørn Lie <bjorn.lie@gmail.com> wrote: [...]
Provides: gstreamer-plugins-ugly-orig-addon = %{version} Obsoletes: gstreamer-plugins-ugly-orig-addon < %{version} Provides: gstreamer-plugins-bad-orig-addon = %{version} Obsoletes: gstreamer-plugins-bad-orig-addon < %{version}
Provides/Obsoletes is in place, but I should have used
Obsoletes: gstreamer-plugins-bad-orig-addon Obsoletes: gstreamer-plugins-ugly-orig-addon
without the version check ...
As you noted in a later mail, an unversioned Obsoletes: will bite you if you ever want to re-introduce that package. So please don't use unversioned Obsoletes:
It didn't work because you didn't use "%{version}-%{release}". Without that, it won't correctly obsolete older builds where the version is the same.
Basically, never use "%{version}" for this case, always use "%{version}-%{release}".
While I agree that including the release makes sense (if the version stays the same), I don't like the idea of using variables when it comes to Obsoletes. Obsoletes is one of the rare cases where hardcoded version numbers make sense, in this case (assuming the last version from Packman was 1.18.5-1.1) Obsoletes: gstreamer-plugins-ugly-orig-addon < 1.18.5-2.1 Obsoletes: gstreamer-plugins-bad-orig-addon < 1.18.5.2.1 The difference to using %{version}-%{release} is that the hardcoded variant will still only obsolete < 1.18.5-2.1 when we have gstreamer- plugins 2.42 one day. If you use variables, it will then obsolete < 2.42, which is much broader than initially intended, and probably not really what you want. Yes, I know that our packaging guidelines recommend to use variables even for Obsoletes. I hereby propose to change the guidelines to use hardcoded version numbers for Obsoletes. Regards, Christian Boltz -- Du versuchst, einen Braunkohlebagger im Fahrradständer abzustellen. [Ratti in suse-linux zur Frage, wie man Mails mit >=100 MB senden kann]
Hello, thanks for working on packman. On Sat, Jan 29, 2022 at 12:16:40PM +0100, Bjørn Lie wrote:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
Looks like both the 32bit and the 64bit gstreamer-plugins-bad-codecs depend on libopenh264 which can be installed only in one of 32bit or 64bit so both 32bit and 64bit gstreamer cannot use the codec: Problem: the to be installed gstreamer-plugins-bad-codecs-32bit-1.18.5-3.1.x86_64 requires 'libopenh264.so.6', but this requirement cannot be provided not installable providers: libopenh264-6-2.1.1-1.32.i586[packman-essentials] Solution 1: Following actions will be done: install libopenh264-6-2.1.1-1.32.i586 despite the inferior architecture architecture change of libopenh264-6-2.1.1-1.32.x86_64 to libopenh264-6-2.1.1-1.32.i586 architecture change of gstreamer-plugins-bad-codecs-1.18.5-3.1.x86_64 to gstreamer-plugins-bad-codecs-1.18.5-3.1.i586 Solution 2: do not install gstreamer-plugins-bad-codecs-32bit-1.18.5-3.1.x86_64 Solution 3: break gstreamer-plugins-bad-codecs-32bit-1.18.5-3.1.x86_64 by ignoring some of its dependencies Sounds like the libopenh264 needs some fix to be usable both 32bit and 64bit at the same time. Thanks Michal
to., feb. 3 2022 at kl. 20.55 +0100 +0100 skrev Michal Suchánek <msuchanek@suse.de> følgende:
Sounds like the libopenh264 needs some fix to be usable both 32bit and 64bit at the same time.
Thanks
Michal
Right - missing baselibs.conf in openh264 And now we are REALLY way of what should be discussed here on the factory list ;-) Please lets move this to packman if in need of more discussion. /Bjørn
Hi, I'm the maintainer of the opi tool that is in the oss repo and can help installing codecs from packman using "opi codecs" command. I implemented the changes for tw in this PR for opi: https://github.com/openSUSE/opi/pull/92 Could someone have a look if this makes sense? Also will this change affect the release after 15.4? Regards, Dominik Am 29.01.22 um 12:16 schrieb Bjørn Lie:
Greetings all
Letting you all know that we have removed the packages gstreamer-plugins-bad and gstreamer-plugins-ugly (and their sub-packages) for Tumbleweed. Leap stays as it has been in the past.
In the future only the plugins not available in main oss from these 2 will be packaged and shipped (gstreamer-plugins-libav will continue to exist for now).
This means that user will encounter that zypper expect/wants you to do a vendor change for a lot of gstreamer packages if you currently have them installed from the packman repo. This is expected and you should go ahead with the vendor change.
Once done, you should be left with only 2 (or 4 if you have gst-*32-bits installed aswell). Those will be:
gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecs
(and depending on 32-bit or not)
gstreamer-plugins-bad-codecs-32bit gstreamer-plugins-ugly-codecs-32bit
/Bjørn
ti., mars 1 2022 at kl. 15.04 +0100 +0100 skrev Dominik Heidler <dheidler@suse.de> følgende:
Hi,
I'm the maintainer of the opi tool that is in the oss repo and can help installing codecs from packman using "opi codecs" command.
I implemented the changes for tw in this PR for opi: https://github.com/openSUSE/opi/pull/92
Could someone have a look if this makes sense?
Also will this change affect the release after 15.4?
Regards, Dominik
Yes that looks fine. Installing both gstreamer-bad/ugly-codecs AND gstreamer-libav is a bit of a "overkill" but fine, will not hurt anything. Personally I do not have gst-libav installed, but I suppose for the casual enduser this will give the least headache. One could also question the install of pipewire-aptx, as not everyone will have pipewire installed I suppose, but that is up to you. "Current setup" will be the default for future releases yes, at least that is the plan as of now. /Bjørn
participants (6)
-
Bjørn Lie -
Christian Boltz -
Dominik Heidler -
Manfred Hollstein -
Michal Suchánek -
Neal Gompa