[opensuse-factory] Latest 'zypper up' brings in 'brltty', 'qemu' and ALL dependencies - Why?
Guys, This was a bit surprising. last night a simply zypper up on 4.23 and 15.0 brought in new packages 'brltty' and 'qemu' requiring ~120M of storage for packages that will not even work on my system and slowed desktop startup and responsiveness to a crawl on Virtualbox installs. Why is the braille driver and qemu being pulled in as recommends on a simple zypper up? In order to restore desktop startup speed and fix the virtualbox installs I had to specifically get rid of the unneeded packages with # zypper rm --clean-deps brltty qemu There are probably less than 0.01% of users with hardware capable of braille interpretation. What package is responsible for this, or how can I figure it out? This seems like a complete unintended consequence to some packaging change. There is no reason we should no have to run: # zypper up --no-recommends just to prevent unwanted software from being installed on update. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
David C. Rankin schreef op 2019-02-23 21:57:
Guys,
This was a bit surprising. last night a simply zypper up on 4.23 and 15.0 brought in new packages 'brltty' and 'qemu' requiring ~120M of storage for packages that will not even work on my system and slowed desktop startup and responsiveness to a crawl on Virtualbox installs.
It is worse. Even "zypper patch" will install it # zypper lp Repository | Name | Category | Severity | Interactive | Status | Summary ---------------------+-------------------+----------+----------+-------------+--------+-------------------------- Updates-os-Leap_15.0 | openSUSE-2019-232 | security | moderate | --- | needed | Security update for build # zypper patch The following 27 NEW packages are going to be installed: kvm_stat libcacard0 libfdt1 libpmem1 librbd1 libspice-server1 libusbredirparser1 libvdeplug3 libvirglrenderer0 ovmf pmdk qemu qemu-block-curl qemu-block-rbd qemu-ipxe qemu-ksm qemu-kvm qemu-ovmf-x86_64 qemu-seabios qemu-sgabios qemu-tools qemu-ui-curses qemu-ui-gtk qemu-ui-sdl qemu-vgabios qemu-x86 xen-libs The following NEW patch is going to be installed: openSUSE-2019-232 The following 3 packages are going to be upgraded: build build-mkbaselibs build-mkdrpms 3 packages to upgrade, 27 new. Overall download size: 21.3 MiB. Already cached: 0 B. After the operation, additional 67.2 MiB will be used.
Why is the braille driver and qemu being pulled in as recommends on a simple zypper up?
In order to restore desktop startup speed and fix the virtualbox installs I had to specifically get rid of the unneeded packages with
# zypper rm --clean-deps brltty qemu
There are probably less than 0.01% of users with hardware capable of braille interpretation. What package is responsible for this, or how can I figure it out?
This seems like a complete unintended consequence to some packaging change. There is no reason we should no have to run:
# zypper up --no-recommends
just to prevent unwanted software from being installed on update.
-- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
H.Merijn Brand wrote:
David C. Rankin schreef op 2019-02-23 21:57:
Guys,
This was a bit surprising. last night a simply zypper up on 4.23 and 15.0 brought in new packages 'brltty' and 'qemu' requiring ~120M of storage for packages that will not even work on my system and slowed desktop startup and responsiveness to a crawl on Virtualbox installs.
It is worse. Even "zypper patch" will install it
It depends on the state of your current system - this is from a standard desktop system in the office: (sorry about the noise): # zypper patch Loading repository data... Reading installed packages... Patch 'openSUSE-2018-1319-1' is optional. Use 'zypper in patch:openSUSE-2018-1319' to install it, or '--with-optional' to include all optional patches. Patch 'openSUSE-2018-1307-1' is optional. Use 'zypper in patch:openSUSE-2018-1307' to install it, or '--with-optional' to include all optional patches. Patch 'openSUSE-2018-1305-1' is optional. Use 'zypper in patch:openSUSE-2018-1305' to install it, or '--with-optional' to include all optional patches. Resolving package dependencies... The following 7 items are locked and will not be changed by any action: Available: btrfsmaintenance btrfsprogs chrony firewalld grub2 libbtrfs0 snapper The following 18 NEW patches are going to be installed: openSUSE-2019-152 openSUSE-2019-155 openSUSE-2019-164 openSUSE-2019-174 openSUSE-2019-175 openSUSE-2019-178 openSUSE-2019-179 openSUSE-2019-181 openSUSE-2019-183 openSUSE-2019-184 openSUSE-2019-186 openSUSE-2019-188 openSUSE-2019-197 openSUSE-2019-203 openSUSE-2019-220 openSUSE-2019-221 openSUSE-2019-223 openSUSE-2019-224 The following 68 packages are going to be upgraded: avahi avahi-lang curl glib2-lang glib2-tools gtk3-data gtk3-immodule-amharic gtk3-immodule-inuktitut gtk3-immodule-thai gtk3-immodule-vietnamese gtk3-lang gtk3-schema gtk3-tools ipset kernel-firmware kernel-macros kimageformats libavahi-client3 libavahi-client3-32bit libavahi-common3 libavahi-common3-32bit libavahi-core7 libavahi-glib1 libcurl4 libdns_sd libfreebl3 libgio-2_0-0 libgio-2_0-0-32bit libglib-2_0-0 libglib-2_0-0-32bit libgmodule-2_0-0 libgmodule-2_0-0-32bit libgobject-2_0-0 libgobject-2_0-0-32bit libgthread-2_0-0 libgthread-2_0-0-32bit libgtk-3-0 libipset11 liblua5_3-5 libmariadb3 libopenssl-1_1-devel libopenssl1_1 libopenssl1_1-32bit libpython2_7-1_0 libpython2_7-1_0-32bit libpython3_6m1_0 libsoftokn3 libxml2-2 libxml2-2-32bit libxml2-tools mozilla-nss mozilla-nss-certs openssl-1_1 python python-base python-curses python-xml python3 python3-base python3-curses python3-dbm python3-idle python3-tk rollback-helper typelib-1_0-Gtk-3_0 ucode-amd wireless-regdb xrdb The following patch requires a system reboot: openSUSE-2019-203 68 packages to upgrade. Overall download size: 118.2 MiB. Already cached: 0 B. After the operation, additional 804.6 KiB will be used. -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/02/2019 21.57, David C. Rankin wrote:
Guys,
This was a bit surprising. last night a simply zypper up on 4.23 and 15.0 brought in new packages 'brltty' and 'qemu' requiring ~120M of storage for packages that will not even work on my system and slowed desktop startup and responsiveness to a crawl on Virtualbox installs.
Why is the braille driver and qemu being pulled in as recommends on a simple zypper up?
In order to restore desktop startup speed and fix the virtualbox installs I had to specifically get rid of the unneeded packages with
# zypper rm --clean-deps brltty qemu
There are probably less than 0.01% of users with hardware capable of braille interpretation. What package is responsible for this, or how can I figure it out?
This seems like a complete unintended consequence to some packaging change. There is no reason we should no have to run:
# zypper up --no-recommends
Don't. Instead taboo qemu and brltty
just to prevent unwanted software from being installed on update.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Sun, 24 Feb 2019, 12:34:51 +0100, Carlos E. R. wrote:
On 23/02/2019 21.57, David C. Rankin wrote:
[...] This seems like a complete unintended consequence to some packaging change. There is no reason we should no have to run:
# zypper up --no-recommends
Don't. Instead taboo qemu and brltty
No, please! Nobody, other than a developer (or some guys who have to run virtualised systems, but even then, that's a very special case!) _needs_ qemu! If they do, they should select a particular pattern (or profile or role) which pulls in the stuff that's really necessary for it. The whole "Recommends:" is bad from my point of view; it's nothing than a vehicle that gets used to work-around such additional patterns (or profiles or roles). I have to admit there are other examples where a recommended package is sensible, but most of the times, it appears such packages should actually be "Required:". FWIW, FMPOV, "Recommends:" gets abused while there are other ways to help pull in such packages when really needed. brltty is another example; luckily I don't (yet) need such support packages, so why are they recommended to me? Instead, there should be a pattern to pull in such additional support packages when needed. Don't get me wrong, I already have to carry my packages, so don't need additional ones I don't need (yet). Cheers. l8er manfred
Am 24.02.19 um 15:17 schrieb Manfred Hollstein:
On Sun, 24 Feb 2019, 12:34:51 +0100, Carlos E. R. wrote:
On 23/02/2019 21.57, David C. Rankin wrote:
[...] This seems like a complete unintended consequence to some packaging change. There is no reason we should no have to run:
# zypper up --no-recommends
Don't. Instead taboo qemu and brltty
No, please! Nobody, other than a developer (or some guys who have to run virtualised systems, but even then, that's a very special case!) _needs_ qemu!
Well, but then a non-developer (or some guys who have to do packaging, but even then, that's a very special case!) do _neeed_ build. So if build.rpm is installed, recommending qemu is not such a stupid idea.
If they do, they should select a particular pattern (or profile or role) which pulls in the stuff that's really necessary for it. The whole "Recommends:" is bad from my point of view; it's nothing than a vehicle that gets used to work-around such additional patterns (or profiles or roles). I have to admit there are other examples where a recommended package is sensible, but most of the times, it appears such packages should actually be "Required:". FWIW, FMPOV, "Recommends:" gets abused while there are other ways to help pull in such packages when really needed.
Recommends is just not fine grained enough, so I agree here (I always use "--no-recommends", dealing with the fallout of this is much easier for me than having to buy a bigger disk every three months ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Feb 24 15:39 Stefan Seyfried wrote (excerpt):
Am 24.02.19 um 15:17 schrieb Manfred Hollstein (excerpt):
The whole "Recommends:" is bad from my point of view; it's nothing than a vehicle that gets used to work-around such additional patterns (or profiles or roles)
Recommends is just not fine grained enough
What exactly should "fine grained Recommends" be and how exactly would they help - i.e. what exactly must be specified in the RPM spec file to get things work as intended - by the way: what is actually intended?
From my current point of view I agree with Manfred Hollstein, see my reasoning in
https://lists.opensuse.org/opensuse-factory/2018-02/msg00924.html https://lists.opensuse.org/opensuse-factory/2018-09/msg00182.html https://lists.opensuse.org/opensuse-factory/2018-09/msg00185.html https://lists.opensuse.org/opensuse-factory/2018-09/msg00200.html which is of course too much to read ... ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Carlos E. R. -
David C. Rankin -
H.Merijn Brand -
Johannes Meixner -
Manfred Hollstein -
Per Jessen -
Stefan Seyfried