What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
Olaf
On Mon, Apr 18, 2016 at 1:17 PM, Olaf Hering olaf@aepfle.de wrote:
What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
Not sure I understand the question. Is package currently installed (rpm -q)? If yes, what is the problem with removing it?
On Mon, Apr 18, Andrei Borzenkov wrote:
On Mon, Apr 18, 2016 at 1:17 PM, Olaf Hering olaf@aepfle.de wrote:
What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
Not sure I understand the question. Is package currently installed (rpm -q)? If yes, what is the problem with removing it?
I have not tried to simulate this in practice, what would happen is: If ffmpeg-devel is installed it Requires libavcodec-devel = version. If ffmpeg is updated to the next version then 'libavcodec-devel = version', required by ffmpeg-devel, does not exist anymore. As a result the update of the entire ffmpeg related packages is blocked.
Olaf
On Mon, Apr 18, 2016 at 1:27 PM, Olaf Hering olaf@aepfle.de wrote:
On Mon, Apr 18, Andrei Borzenkov wrote:
On Mon, Apr 18, 2016 at 1:17 PM, Olaf Hering olaf@aepfle.de wrote:
What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
Not sure I understand the question. Is package currently installed (rpm -q)? If yes, what is the problem with removing it?
I have not tried to simulate this in practice, what would happen is: If ffmpeg-devel is installed it Requires libavcodec-devel = version. If ffmpeg is updated to the next version then 'libavcodec-devel = version', required by ffmpeg-devel, does not exist anymore.
Presumably newer version of ffmpeg-devel would require newer version of libavcodec-devel that would exist at this point?
As a result the update of the entire ffmpeg related packages is blocked.
Olaf
How about the use of "Obsoletes: ffmpeg-devel" in one or all of the affected packages? No extra hassle this way.
- Yamaban
On Monday 2016-04-18 12:27, Olaf Hering wrote:
I have not tried to simulate this in practice, what would happen is: If ffmpeg-devel is installed it Requires libavcodec-devel = version. If ffmpeg is updated to the next version then 'libavcodec-devel = version', required by ffmpeg-devel, does not exist anymore. As a result the update of the entire ffmpeg related packages is blocked.
Apart from the weakremover thing (which only runs on dup), what I did in cases like these is simply continue providing that -devel for a while and placing it in a most-grabbing package:
libavdevice requires most of the av packages by linkage, so that is the place I would add Obsoletes/Provides to.
On Mon, 2016-04-18 at 12:17 +0200, Olaf Hering wrote:
What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
If ffmpeg-devel no longer exists in openSUSE:Factory, it is automatically added as a weakremoves() in the _product and 'zypper dup' takes care of removing it IFF it can be removed without breaking dependencies of other stuff on the system.
This list is defined in https://build.opensuse.org/package/view_file/openSUSE:Factory/_product/ obsoletepackages.inc?expand=1
Cheers, Dominique
On Mon, Apr 18, Dominique Leuenberger / DimStar wrote:
https://build.opensuse.org/package/view_file/openSUSE:Factory/_product/obsol...
Thanks.
How are packages entered there? Unrelated to ffmpeg-devel, 'zypper packages --orphaned' lists a few items which should be part of that list.
Olaf
On Mon, 2016-04-18 at 12:46 +0200, Olaf Hering wrote:
On Mon, Apr 18, Dominique Leuenberger / DimStar wrote:
https://build.opensuse.org/package/view_file/openSUSE:Factory/_prod uct/obsoletepackages.inc?expand=1
Thanks.
How are packages entered there? Unrelated to ffmpeg-devel, 'zypper packages --orphaned' lists a few items which should be part of that list.
It's auto-generated based on 'released produced to TW upgrade path'. I don't think we have a TW(Random)-to-TW upgrade test case.
Cheers, Dominique
On Mon, Apr 18, Dominique Leuenberger / DimStar wrote:
On Mon, 2016-04-18 at 12:46 +0200, Olaf Hering wrote:
On Mon, Apr 18, Dominique Leuenberger / DimStar wrote:
https://build.opensuse.org/package/view_file/openSUSE:Factory/_product/obsol...
Thanks.
How are packages entered there? Unrelated to ffmpeg-devel, 'zypper packages --orphaned' lists a few items which should be part of that list.
It's auto-generated based on 'released produced to TW upgrade path'. I don't think we have a TW(Random)-to-TW upgrade test case.
Is there a way to add known-broken packages manually? Since some time three broken packages are reported during dup: libhdf5-10 libhdf5_hl10 liborcus-0_10-0
File /usr/lib64/libhdf5.so.10.1.0 from install of libhdf5-10-1.8.16-3.1.x86_64 (oss) conflicts with file from package libhdf5-11-1.8.16-1.1.x86_64 (@System)
File /usr/lib64/libhdf5_hl.so.10.0.2 from install of libhdf5_hl10-1.8.16-3.1.x86_64 (oss) conflicts with file from package libhdf5_hl11-1.8.16-1.1.x86_64 (@System)
File /usr/lib64/liborcus-0.11.so.0.0.0 from install of liborcus-0_11-0-0.11.0-2.2.x86_64 (oss) conflicts with file from package liborcus-0_10-0-0.11.0-1.2.x86_64 (@System)
File /usr/lib64/liborcus-mso-0.11.so.0.0.0 from install of liborcus-0_11-0-0.11.0-2.2.x86_64 (oss) conflicts with file from package liborcus-0_10-0-0.11.0-1.2.x86_64 (@System)
File /usr/lib64/liborcus-parser-0.11.so.0.0.0 from install of liborcus-0_11-0-0.11.0-2.2.x86_64 (oss) conflicts with file from package liborcus-0_10-0-0.11.0-1.2.x86_64 (@System)
File /usr/lib64/liborcus-spreadsheet-model-0.11.so.0.0.0 from install of liborcus-0_11-0-0.11.0-2.2.x86_64 (oss) conflicts with file from package liborcus-0_10-0-0.11.0-1.2.x86_64 (@System)
Olaf
On Mon, May 02, Olaf Hering wrote:
Is there a way to add known-broken packages manually?
If such list of orphaned packages gets created anyway, the following list of packages from the past 9 months:
zypper packages --orphaned | awk '{print $5 }' | xargs rpm -q --qf '%{DISTRIBUTION} %{NAME}\n' | grep -v debug | sort | awk '/ Factory / { print $3 }' boost-license1_58_0 boost-license1_59_0 libboost_atomic1_58_0 libboost_atomic1_59_0 libboost_chrono1_58_0 libboost_chrono1_59_0 libboost_container1_58_0 libboost_container1_59_0 libboost_context1_58_0 libboost_context1_59_0 libboost_coroutine1_58_0 libboost_coroutine1_59_0 libboost_date_time1_58_0 libboost_date_time1_59_0 libboost_filesystem1_58_0 libboost_filesystem1_59_0 libboost_graph1_58_0 libboost_graph1_59_0 libboost_iostreams1_58_0 libboost_iostreams1_59_0 libboost_locale1_58_0 libboost_locale1_59_0 libboost_log1_58_0 libboost_log1_59_0 libboost_math1_58_0 libboost_math1_59_0 libboost_program_options1_58_0 libboost_program_options1_59_0 libboost_python1_58_0 libboost_python1_59_0 libboost_random1_58_0 libboost_random1_59_0 libboost_regex1_58_0 libboost_regex1_59_0 libboost_serialization1_58_0 libboost_serialization1_59_0 libboost_signals1_58_0 libboost_signals1_59_0 libboost_system1_58_0 libboost_system1_59_0 libboost_test1_58_0 libboost_test1_59_0 libboost_thread1_58_0 libboost_thread1_59_0 libboost_timer1_58_0 libboost_timer1_59_0 libboost_wave1_58_0 libboost_wave1_59_0 libcamel-1_2-54 libdialog12 libdns161 libgdict-1_0-9 libgpaste4 libhdf5-11 libhdf5_hl11 libicu55_1 libicu55_1-ledata libicu56_1 libicu56_1-ledata libisc148 libisl13 libixion-0_10-0 liblmdb-0_9_16 libmicrohttpd11 libminiupnpc15 libnis1 libntfs-3g86 liborcus-0_10-0 libpoppler55 libpoppler56 libpoppler57 libpoppler58 libpsl0 libsgutils2-1_41-2 libsuitesparseconfig-4_4_5 libvpx2
Olaf
On Tue, May 03, Olaf Hering wrote:
On Mon, May 02, Olaf Hering wrote:
Is there a way to add known-broken packages manually?
If such list of orphaned packages gets created anyway, the following list of packages from the past 9 months:
zypper packages --orphaned | awk '{print $5 }' | xargs rpm -q --qf '%{DISTRIBUTION} %{NAME}\n' | grep -v debug | sort | awk '/ Factory / { print $3 }'
OBS will likely play pingpong with this, so please accept it manually.
https://build.opensuse.org/request/show/396407
Olaf
On Tue, May 03, Olaf Hering wrote:
Thanks for extending the list.
boost-license1_58_0
Most or all of the boot packages lack the trailing "_0". Since _product does not allow submit requests, here are the remaining ones:
i | @System | boost-license1_58_0 | 1.58.0-3.4 | noarch i | @System | boost-license1_59_0 | 1.59.0-4.1 | noarch i | @System | libboost_date_time1_58_0 | 1.58.0-3.4 | x86_64 i | @System | libboost_date_time1_59_0 | 1.59.0-4.1 | x86_64 i | @System | libboost_iostreams1_58_0 | 1.58.0-3.4 | x86_64 i | @System | libboost_iostreams1_59_0 | 1.59.0-4.1 | x86_64 i | @System | libboost_system1_58_0 | 1.58.0-3.4 | x86_64 i | @System | libboost_system1_59_0 | 1.59.0-4.1 | x86_64 i | @System | libboost_thread1_58_0 | 1.58.0-3.4 | x86_64 i | @System | libboost_thread1_59_0 | 1.59.0-4.1 | x86_64 i | @System | libdns160 | 9.10.2-9.1 | x86_64 i | @System | libisc148 | 9.10.2P4-13.1 | x86_64 i | @System | libpoppler52 | 0.33.0-1.3 | x86_64 i | @System | libpoppler56-debuginfo | 0.37.0-1.1 | x86_64 i | @System | libprocps4 | 3.3.10-3.2 | x86_64 i | @System | libsgutils2-1_40-2 | 1.40-1.2 | x86_64 i | @System | openldap2-client-debugsource | 2.4.42-18.2 | x86_64
Olaf
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
And from yet another system:
boost-license1_56_0 lib++dfb-1_7-6 libboost_system1_56_0 libboost_thread1_56_0 libdirectfb-1_7-6 libdns146 libicu54_1 libicu54_1-ledata libimobiledevice5 libisc142 libpoppler47 libpoppler48 libpoppler49 libwebp5
Olaf
On Sonntag, 22. Mai 2016, 21:20:37 wrote Olaf Hering:
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
actually, it should work.
Adrian Schröter adrian@suse.de writes:
On Sonntag, 22. Mai 2016, 21:20:37 wrote Olaf Hering:
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
actually, it should work.
But factory-auto always rejects them.
Andreas.
On Montag, 23. Mai 2016, 09:37:29 wrote Andreas Schwab:
Adrian Schröter adrian@suse.de writes:
On Sonntag, 22. Mai 2016, 21:20:37 wrote Olaf Hering:
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
actually, it should work.
But factory-auto always rejects them.
Shoot them ... ;)
What is the given reason?
On Mon, 2016-05-23 at 10:32 +0200, Adrian Schröter wrote:
On Montag, 23. Mai 2016, 09:37:29 wrote Andreas Schwab:
Adrian Schröter adrian@suse.de writes:
On Sonntag, 22. Mai 2016, 21:20:37 wrote Olaf Hering:
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
actually, it should work.
But factory-auto always rejects them.
Shoot them ... ;)
What is the given reason?
submission not coming from a devel project
and _product has no devel project... and I won't set one :)
On Mon, May 23, Dominique Leuenberger / DimStar wrote:
and _product has no devel project... and I won't set one :)
Fix factory-auto instead so that others can contribute directly instead of bothering you via email.
Olaf
On Mon, May 23, Adrian Schröter wrote:
On Sonntag, 22. Mai 2016, 21:20:37 wrote Olaf Hering:
On Fri, May 20, Olaf Hering wrote:
Since _product does not allow submit requests, here are the remaining ones:
actually, it should work.
It has no devel project, so some autoscript autorejects it automatically.
Olaf
On Mon, Apr 18, 2016 at 12:34 PM, Dominique Leuenberger / DimStar dimstar@opensuse.org wrote:
On Mon, 2016-04-18 at 12:17 +0200, Olaf Hering wrote:
What are the options to uninstall a removed package? […] So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'.
If ffmpeg-devel no longer exists in openSUSE:Factory, it is automatically added as a weakremoves() in the _product and 'zypper dup' takes care of removing it IFF it can be removed without breaking dependencies of other stuff on the system.
I haven't tested the exact case of of "ffmpeg-devel", but after DUPs we're regularly seeing the problem of previous-openSUSE-release packages still being installed, both in the supported one-version DUP case and, unsurprisingly, the unsupported two-or-more-versions DUP case (the latter often causes, unsurprisingly, all other kinds of problems).
We're doing our DUPs with a (python-)fabric script; here is an incomplete list of packages we have encountered. Some might be cause be the mentioned two-version DUPs:
------------------------------ 8< ------------------------------ if release_after_dup == '13.1': _rm_if_installed("libblocxx6") # removes "limal", too. _rm_if_installed("libpng15-15") _rm_if_installed("libserf-1-0") _rm_if_installed("libyui-ncurses4") _rm_if_installed("libyui4") _rm_if_installed("limal") # should already be removed by this point, see above. _rm_if_installed("microcode_ctl") _rm_if_installed("yast2-mouse") _rm_if_installed("cpp47") _rm_if_installed("gcc47") _rm_if_installed("kernel-desktop") _rm_if_installed("libarchive12") _rm_if_installed("libcolord1") _rm_if_installed("libicu49") _rm_if_installed("libimobiledevice3") _rm_if_installed("libxtables9") _rm_if_installed("xtables-addons-kmp-default") _rm_if_installed("cantarell-fonts") _rm_if_installed("desktop-translations") _rm_if_installed("ghostscript-x11") _rm_if_installed("gxditview") _rm_if_installed("libX11-xcb1") _rm_if_installed("libXpm-tools") _rm_if_installed("libjpeg62") _rm_if_installed("libply-splash-core2") _rm_if_installed("libproxy1-config-gnome3") _rm_if_installed("ypbind") _rm_if_installed("yp-tools") _rm_if_installed("crda") _rm_if_installed("nfs-client") _rm_if_installed("nfsidmap") _rm_if_installed("wireless-tools") _rm_if_installed("wireless-regdb") _rm_if_installed("xorg-x11-libs") _rm_if_installed("bundle-lang-gnome-de") _rm_if_installed("bundle-lang-gnome-en") _rm_if_installed("bundle-lang-gnome-extras-de") _rm_if_installed("bundle-lang-gnome-extras-en") _rm_if_installed("gnome-icon-theme-extras") _rm_if_installed("fbset") _rm_if_installed("gsettings-backend-dconf") _rm_if_installed("gtk2-immodule-inuktitut") _rm_if_installed("gtk2-immodule-thai") _rm_if_installed("gtk2-immodule-vietnamese") _rm_if_installed("gtk3-immodule-amharic") _rm_if_installed("gtk3-immodule-inuktitut") _rm_if_installed("gtk3-immodule-thai") _rm_if_installed("gtk3-immodule-vietnamese") _rm_if_installed("nscd") _rm_if_installed("libXaw7") _rm_if_installed("libXmu6") _rm_if_installed("ntfs-3g") _rm_if_installed("libntfs-3g83") _rm_if_installed("libyui-ncurses-pkg4") if release_after_dup == '13.2': _rm_if_installed("cryptsetup-mkinitrd") _rm_if_installed("libgcrypt11") _rm_if_installed("libicu51_2") _rm_if_installed("libicu51_2-data") _rm_if_installed("libjson0") _rm_if_installed("libnl1") _rm_if_installed("libprocps1") _rm_if_installed("libyui-ncurses5") _rm_if_installed("libyui5") _rm_if_installed("ruby20") _rm_if_installed("gtk3-theming-engine-adwaita") _rm_if_installed("libplist1") _rm_if_installed("libupower-glib1") _rm_if_installed("libxkbcommon0") _rm_if_installed("gnome-icon-theme") _rm_if_installed("gtk2-metatheme-adwaita") _rm_if_installed("gtk3-metatheme-adwaita") _rm_if_installed("cantarell-fonts") _rm_if_installed("gcr-viewer") _rm_if_installed("gtk2-theming-engine-adwaita") _rm_if_installed("metatheme-adwaita-common") _rm_if_installed("yast2-x11") if release_after_dup == 'Leap_42.1': _rm_if_installed("branding-basedonopensuse") _rm_if_installed("bundle-lang-common-ar") _rm_if_installed("bundle-lang-common-en") _rm_if_installed("cryptsetup-mkinitrd") _rm_if_installed("dhcpcd") _rm_if_installed("grub2-branding-basedonopensuse") _rm_if_installed("libdirectfb-1_6-0") _rm_if_installed("libgcrypt11") _rm_if_installed("libicu51_2") _rm_if_installed("libicu51_2-data") _rm_if_installed("libimobiledevice4") _rm_if_installed("libjson0") _rm_if_installed("libmozjs185-1_0") _rm_if_installed("libplist1") _rm_if_installed("libprocps1") _rm_if_installed("libpyglib-gi-2_0-python2-0") _rm_if_installed("libudev0") _rm_if_installed("libupower-glib1") _rm_if_installed("libusbmuxd2") #redundant (removed with libplist1) _rm_if_installed("libyui-ncurses5") _rm_if_installed("libyui5") #redundant (libyui-ncurses5) _rm_if_installed("libzmq3") _rm_if_installed("pm-utils") _rm_if_installed("ruby20") _rm_if_installed("rubygem-fast_gettext") #redundant (ruby20) _rm_if_installed("rubygem-ruby-dbus") #redundant (ruby20) _rm_if_installed("suspend") #redundant (libgcrypt11) ------------------------------ >8 ------------------------------
Not all of these packages are caused by the problem the OP has; some are just packages we do not need or want on our old servers, so we remove them during DUP; however, as we do not track the reason for removal, I sadly can't tell which is which. (I DUPed a server from 13.1 to Leap today and at least the following 13.1 packages were still installed afterwards: branding-basedonopensuse bundle-lang-common-ar cryptsetup-mkinitrd dhcpcd grub2-branding-basedonopensuse libicu51_2 libicu51_2-data ruby20 rubygem-fast_gettext rubygem-ruby-dbus.)
To detect such packages *after* a DUP, we do something like this since around openSUSE 11.x (example after a DUP to Leap): ------------------------------ 8< ------------------------------ rpm -qa --qf '%{name}-%{version} %{distribution}\n' | grep -v 'openSUSE[ _:]Leap[ _:]42.1' | grep -v '(none)' | sort ------------------------------ >8 ------------------------------