11:42 a.m.
Hello
It is an often experience that I try to remove a package(ex: bluez, kernel,
gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical
packages, which has no connection(ex. kernel => Xchat OR bluez => gedit etc.) with
the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf,
which should help remove only the leaf node packages and nothing else. So I set it.
But after setting remove_leaf_only=1, I can remove _none_ of the packages because of the
dependency issues. Even when I try to remove _all_ of the dependency packages I'm
barely allowed to remove but a single package. (see below)
I wonder why is this so? Is this an error in the way packages are built OR isit
yum(8)'s dependency resolving algorithm that is broken? I've also seen instances
wherein yum installs _new_ package during yum update. All this does not seem good at all.
Many of the folks, with whom I've argued for Fedora, cite yum(8) to be the foremost
reason for not liking Fedora.
Does the new DNF(https://fedoraproject.org/wiki/Features/DNF) plans to address these
issues? Till then is there a known remedy for yum(8)'s illness??
===
[~ @ 21:44]# yum remove bluez
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package bluez.x86_64 0:4.101-9.fc19 will be erased
---> Keeping package: bluez-4.101-9.fc19.x86_64 due to
pulseaudio-module-bluetooth-3.0-10.fc19.x86_64
--> Finished Dependency Resolution
[~ @ 21:45]#
[~ @ 21:46]# yum remove pulseaudio-module-bluetooth
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased
---> Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to
1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64
--> Finished Dependency Resolution
[~ @ 21:46]#
[~ @ 21:46]# yum remove gnome-bluetooth
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased
---> Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to
bluez-4.101-9.fc19.x86_64
--> Finished Dependency Resolution
[~ @ 21:46]#
[~ @ 21:46]# yum remove gnome-bluetooth bluez pulseaudio-module-bluetooth
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package bluez.x86_64 0:4.101-9.fc19 will be erased
---> Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased
---> Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to
gnome-shell-3.8.4-2.fc19.x86_64
---> Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased
---> Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to
1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================
Package Arch Version
Repository Size
=======================================================================================
Removing:
bluez x86_64 4.101-9.fc19
@updates 1.9 M
Transaction Summary
=======================================================================================
Remove 1 Package
Installed size: 1.9 M
Is this ok [y/N]: N
===
Thank you.
---
Regards
-Prasad
http://feedmug.com
11:49 a.m.
Am 12.10.2013 18:42, schrieb P J P:
It is an often experience that I try to remove a package(ex: bluez,
kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of
critical packages, which has no connection(ex. kernel => Xchat OR bluez => gedit
etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in
yum.conf, which should help remove only the leaf node packages and nothing else. So I set
it.
But after setting remove_leaf_only=1, I can remove _none_ of the packages because of the
dependency issues. Even when I try to remove _all_ of the dependency packages I'm
barely allowed to remove but a single package. (see below)
I wonder why is this so? Is this an error in the way packages are built OR isit
yum(8)'s dependency resolving algorithm that is broken? I've also seen instances
wherein yum installs _new_ package during yum update. All this does not seem good at all.
Many of the folks, with whom I've argued for Fedora, cite yum(8) to be the foremost
reason for not liking Fedora.
dependency chains
* many packages depend on others
* they are depend on others too
* they are depend on libraries
* you want to remove something which provides required libraries/binaries
that's why i get that mad if packagers careless add new deps because
they enable whatever function in a package instead split the new
ones in additional subpackages
on a tiny setup one small added dependency often pulls *a lot* of
other dependencies the user did not use and install for good reasons
like keep the footprint small and make dist-upgrades fast
noon
On Saturday, 12 October 2013 10:19 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
that's why i get that mad if packagers careless add new deps because
they enable whatever function in a package instead split the new
ones in additional subpackages
I see. If it is a packaging error, how does DNF plan to address it?
on a tiny setup one small added dependency often pulls *a lot* of
other dependencies the user did not use and install for good reasons
like keep the footprint small and make dist-upgrades fast
True, couldn't agree more. I too strive to install the bare minimum required
packages, but invariably I lose after the first $ yum update post system install. :(
---
Regards
-Prasad
http://feedmug.com
12:13 p.m.
Am 12.10.2013 19:00, schrieb P J P:
> On Saturday, 12 October 2013 10:19 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> that's why i get that mad if packagers careless add new deps because
> they enable whatever function in a package instead split the new
> ones in additional subpackages
I see. If it is a packaging error, how does DNF plan to address it?
*why* should it be addressed in yum or DNF?
if a package pulls un-needed dependencies the package has
to be fixed and *not* worked around it - period
12:34 p.m.
On Saturday, 12 October 2013 10:43 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
*why* should it be addressed in yum or DNF?
if a package pulls un-needed dependencies the package has
to be fixed and *not* worked around it - period
Yes, agreed. But that might probably involve fixing the package review process wherein
a new package is introduced. Once the package is approved and enters repositories,
subsequent updates could introduce new dependencies. These updates do not go through any
manual review process. Spotting dependency errors by inspecting the .spec file seems like
quite a task, at least it's difficult to spot without manual inspection.
One solution could be for Yum(8) or DNF to only list the dependency packages to caution a
user that if you remove the said package, these many packages would be affected. But
prompt him to remove only the selected package and not 100 others along with it.
Ie. If I ask to remove package bluez, do let me know that 100 other packages might not
work, but prompt me to remove only and only package bluez and not the 100 other affected
packages. This would significantly simplify user's decision making and thus improve
user experience too.
---
Regards
-Prasad
http://feedmug.com
12:53 p.m.
Am 12.10.2013 19:34, schrieb P J P:
> On Saturday, 12 October 2013 10:43 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> *why* should it be addressed in yum or DNF?
>
> if a package pulls un-needed dependencies the package has
> to be fixed and *not* worked around it - period
Yes, agreed. But that might probably involve fixing the package review process wherein a
new package
is introduced. Once the package is approved and enters repositories, subsequent updates
could introduce
new dependencies. These updates do not go through any manual review process.
and yum/dnf on the users end can't change anything here
the manual review most likely also because if you compile
with a additional --with-whatever flag you may introduce a
dependency not visible in the SPEC nor on many machines
which may have installed it already for other reasons
this could only be done on the infrastructure by verify
the implicit and explicit "Requires" against the previous
build and supsend push the package until a manual review
Ie. If I ask to remove package bluez, do let me know that 100 other
packages might not work,
but prompt me to remove only and only package bluez and not the 100 other affected
packages.
This would significantly simplify user's decision making and thus improve user
experience too.
if you understand how modern software with shared libraries is
working you won't come to this idea - you have finally no clue
which libraries and core components are broken by doing so and
there is a good chance that you break the whole setup
if you want get a feeling in waht these ends type the follwoing as root
after you prepeared a rescue-disc because not rpm, nor yum nor even sshd
will work any longer and you need to copy the package files by hand
to their location - have fun, tried it in a VM
"rpm -e --nodeps nss-softokn-freebl"
1:16 p.m.
On Saturday, 12 October 2013 11:23 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
if you want get a feeling in waht these ends type the follwoing as root
after you prepeared a rescue-disc because not rpm, nor yum nor even sshd
will work any longer and you need to copy the package files by hand
to their location - have fun, tried it in a VM
"rpm -e --nodeps nss-softokn-freebl"
Well, with --nodeps you already allow rpm to remove a package without knowing which
other packages it might affect. I tried it with yum(8) instead, after resolving a huge
list of dependencies possibly involving _every_ installed package it could find, including
libc.so.6 & systemd, finally yum refused to remove it. That is smart.
===
[~ @ 23:30]# yum remove nss-softokn-freebl
...
--> Running transaction check
---> Package foomatic-db.noarch 0:4.0-38.20130604.fc19 will be erased
---> Package icc-profiles-basiccolor-printing2009.noarch 0:1.2.0-3.fc19 will be erased
---> Package kernel-modules-extra.x86_64 0:3.11.3-201.fc19 will be erased
--> Finished Dependency Resolution
Error: Trying to remove "systemd", which is protected
Error: Trying to remove "yum", which is protected
===
Yum(8) already has some intelligence built into it to protect a naive user from possible
disasters. Considering that, it is okay to let user remove other packages at will.
---
Regards
-Prasad
http://feedmug.com
1:34 p.m.
Am 12.10.2013 20:16, schrieb P J P:
> On Saturday, 12 October 2013 11:23 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> if you want get a feeling in what these ends type the follwoing as root
> after you prepeared a rescue-disc because not rpm, nor yum nor even sshd
> will work any longer and you need to copy the package files by hand
> to their location - have fun, tried it in a VM
>
> "rpm -e --nodeps nss-softokn-freebl"
Well, with --nodeps you already allow rpm to remove a package without knowing which other
packages it might affect
and your "list possible affected packages but allow me to remove" ends *exactly*
there
BTW: thank you for quoting out of context and no i am too lazy to search your
original quote, anybody whichg is interested in context may follow the whole thread
2:13 p.m.
On Sunday, 13 October 2013 12:04 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
and your "list possible affected packages but allow me to remove" ends
*exactly* there
No, it does not. If yum is protecting users from un-installing a package which could
render the whole system unusable or unresponsive, what remains is not-so important
packages, which pull in 100 other _unrelated_ packages to the list of packages to be
removed. And invariably user is left with no choice but to type - 'N'; unable to
remove a package.
BTW: thank you for quoting out of context and no i am too lazy to
search your
Sorry, I quoted out of context?
---
Regards
-Prasad
http://feedmug.com
2:20 p.m.
Am 12.10.2013 21:13, schrieb P J P:
> On Sunday, 13 October 2013 12:04 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> and your "list possible affected packages but allow me to remove" ends
> *exactly* there
No, it does not. If yum is protecting users from un-installing a package which could
render the whole system unusable or unresponsive, what remains is not-so important
packages, which pull in 100 other _unrelated_ packages to the list of packages to be
removed. And invariably user is left with no choice but to type - 'N'; unable to
remove a package
"yum install yum-plugin-protectbase" adn core-packages like yum/rpm/kernel are
no longer removed by accident - but that does and *can not* reslove what you want
there is no if and but
if a package has a dependency than it has one - period
there are no soft-depencencies and any hack allow you to remove
a pakcage which is required by another one and ignore this
requirement is pretty dumb
3 p.m.
On Sunday, 13 October 2013 12:50 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
there is no if and but if a package has a dependency than it has one - period
Sure, it has dependency. That does not make it an _absolutely_ requirement to have a
functional system. Because the dependency relationship could be broken. We already agreed
on that, no? Ex. I try to remove package bluez, and yum prompts me to remove gnome-shell,
gthumb, xchat and several other unrelated useful packages.
Does that mean gnome-shell, xchat & gthumb can not function without package bluez? No.
It means dependency relationship is broken.
That is why it is okay to let user remove package 'bluez'. If it breaks
something, user can still re-install bluez without much hassle _if & when_ he/she
figures out that things aren't working as expected. Otherwise it's good riddance,
one unwanted package less.
===
[~ @ 01:00]# yum remove bluez
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package bluez.x86_64 0:4.101-9.fc19 will be erased
--> Processing Dependency: bluez >= 4.34 for package:
pulseaudio-module-bluetooth-3.0-10.fc19.x86_64
--> Processing Dependency: bluez >= 4.42 for package:
1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64
--> Running transaction check
---> Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased
--> Processing Dependency: gnome-bluetooth(x86-64) >= 3.5.5 for package:
gnome-shell-3.8.4-2.fc19.x86_64
--> Processing Dependency: libgnome-bluetooth-applet.so.0()(64bit) for package:
gnome-shell-3.8.4-2.fc19.x86_64
---> Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased
--> Running transaction check
---> Package gnome-shell.x86_64 0:3.8.4-2.fc19 will be erased
...
===
I wonder why is gnome-bluetooth required by gnome-shell, it should be the other way
round, no?
there are no soft-depencencies and any hack allow you to remove
a pakcage which is required by another one and ignore this
requirement is pretty dumb
Heh, and leaving users unable to remove unnecessary packages by prompting them to
remove 100 unrelated useful packages is not dumb?
---
Regards
-Prasad
http://feedmug.com
3:12 p.m.
On Sun, Oct 13, 2013 at 04:00:58 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
Does that mean gnome-shell, xchat & gthumb can not function
without package bluez? No. It means dependency relationship is broken.
In the eyes of the gnome developers the answer is no, it won't work properly
without bluez. That's why there is a dependency.
Perhaps someone could do some work to make gnome work reasonably without
bluez and changes comps so that bluez would get installed by default with
gnome. (So that it would work the same as now in most cases.) And the benefit
of this is to save a small amount of disk space. Given that, most people
are likely to consider this a low priority task compared to other things
they could do to make Fedora better. If this is really important to you,
you should consider engaging the gnome developers to see if there would
be acceptible way to make change and what kinds of tasks would need to be
done.
Your example of removing kernel is even more esoteric. Fedora wouldn't
work at all without it. There may be some reason one might have for wanting
a bunch of Fedora packages installed without the kernel, but you aren't likely
to find anyone interested in making a way to do that.
3:53 p.m.
On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III
<bruno(a)wolff.to> wrote:
Your example of removing kernel is even more esoteric. Fedora wouldn't
work at all without it.
Well, kernel one works when there are multiple kernels installed. It happens when yum
installs a new kernel update. Each kernel brings along its respective kernel-devel,
kernel-header packages.
---
Regards
-Prasad
http://feedmug.com
3:54 p.m.
On Sun, Oct 13, 2013 at 04:53:48 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
> On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III
<bruno(a)wolff.to> wrote:
> Your example of removing kernel is even more esoteric. Fedora wouldn't
> work at all without it.
Well, kernel one works when there are multiple kernels installed. It happens when yum
installs a new kernel update. Each kernel brings along its respective kernel-devel,
kernel-header packages.
Not exactly, but yes the kernel is set up so that multiple versions
can be installed at the same time. You still can't erase them all; you need
to specify versions when you do an erase. There all also depencies on
miminum versions of the kernel, because some things won't work correctly
with older kernels.
3:57 p.m.
Am 12.10.2013 22:53, schrieb P J P:
> On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III
<bruno(a)wolff.to> wrote:
> Your example of removing kernel is even more esoteric. Fedora wouldn't
> work at all without it.
Well, kernel one works when there are multiple kernels installed. It happens when yum
installs a new kernel update. Each kernel brings along its respective kernel-devel,
kernel-header packages.
the kernel is a *special* package, however "kernel-header" is updated
like any other package and only installed in *one* version, only
"kernel" and "kernel-devel" are in context of
"installonly_limit"
may i suggest that you learn basics about dependencies, how linking
works and how dependencies for packages are generated respecting
the linking before you start the next time such a thread?
3:17 p.m.
Am 12.10.2013 22:00, schrieb P J P:
> On Sunday, 13 October 2013 12:50 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> there is no if and but if a package has a dependency than it has one - period
Sure, it has dependency. That does not make it an _absolutely_ requirement to have a
functional system.
*bullshit* you have no clue what the result of a specific broken
dependency would be nor have yum, dnf or even god
Because the dependency relationship could be broken. We already
agreed on that, no?
*fix the package* and *not* the messenger
Ex. I try to remove package bluez, and yum prompts me to remove
gnome-shell, gthumb, xchat and several other unrelated useful packages.
*fix the package* and *not* the messenger
Does that mean gnome-shell, xchat & gthumb can not function
without package bluez?
most likely in case they call libraries
No
says who?
in case of bluez it maybe does not make troubles and the dependency should
be "bluez-libs" and if a package links to /usr/lib64/libbluetooth.so.3 and
yum would allow you to remove it the app would *crash*
It means dependency relationship is broken
there are no soft dependencies in RPM
the whole topic is useless and misguided
*yum and whatever package managmement* are *not* repsponsible for wrong
dependencies and since there are no soft-dpendencies in RPM implemented
the only thing which is broken is the package pull braindead cross-deps
4:32 p.m.
On Sunday, 13 October 2013 1:47 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
*bullshit* you have no clue what the result of a specific broken dependency would be nor
have yum, dnf or even god
Well, when no-one has a clue, assuming the worst is just _one_ way of doing things.
says who?
in case of bluez it maybe does not make troubles and the dependency should
be "bluez-libs" and if a package links to /usr/lib64/libbluetooth.so.3
and yum would allow you to remove it the app would *crash*
Heh..that is what broken dependency means.
*yum and whatever package managmement* are *not* repsponsible for
wrong
dependencies and since there are no soft-dpendencies in RPM implemented
the only thing which is broken is the package pull braindead cross-deps
Yes, we already agreed on this.
---
Regards
-Prasad
http://feedmug.com
4:40 p.m.
Am 12.10.2013 23:32, schrieb P J P:
> On Sunday, 13 October 2013 1:47 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> *bullshit* you have no clue what the result of a specific broken dependency would be
nor have yum, dnf or even god
Well, when no-one has a clue, assuming the worst is just _one_ way of doing things.
no it's the best instead having unpredictable behavior all
over the distribution
> says who?
> in case of bluez it maybe does not make troubles and the dependency should
> be "bluez-libs" and if a package links to /usr/lib64/libbluetooth.so.3
> and yum would allow you to remove it the app would *crash*
Heh..that is what broken dependency means
and why do you want yum/dnf to allow this?
> *yum and whatever package managmement* are *not* repsponsible for
wrong
> dependencies and since there are no soft-dpendencies in RPM implemented
> the only thing which is broken is the package pull braindead cross-deps
Yes, we already agreed on this
so *what* is your topic about?
3:23 p.m.
Am 12.10.2013 22:00, schrieb P J P:
That is why it is okay to let user remove package 'bluez'
[harry@srv-rhsoft:~]$ rpm -qa | grep bluez
bluez-libs-4.101-9.fc19.x86_64
[harry@srv-rhsoft:~]$
as you can see yum or dnf *are not* responsible
ask gnome-upstream why they are too stupid to run without "bluez" while
KDE proves there can be a desktop environment not doing so and so please
realize that the whole thread including it's subject is worthless
2:31 p.m.
On Sun, Oct 13, 2013 at 03:13:41 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
No, it does not. If yum is protecting users from un-installing a package which could
render the whole system unusable or unresponsive, what remains is not-so important
packages, which pull in 100 other _unrelated_ packages to the list of packages to be
removed. And invariably user is left with no choice but to type - 'N'; unable to
remove a package.
They aren't unrelated.
9:35 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sat, Oct 12, 2013 at 02:31:37PM -0500, Bruno Wolff III wrote:
On Sun, Oct 13, 2013 at 03:13:41 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
>
> No, it does not. If yum is protecting users from un-installing a package which
could render the whole system unusable or unresponsive, what remains is not-so important
packages, which pull in 100 other _unrelated_ packages to the list of packages to be
removed. And invariably user is left with no choice but to type - 'N'; unable to
remove a package.
They aren't unrelated.
I believe he is assuming that xchat has a direct relationship with bluez which, I'm
guessing here as I haven't checked, probably isn't the case. Because bluez
affects something that xchat depends on xchat is getting thrown into the pile of things
that will break without bluez. Dependencies aren't always 1:1...
- -- Eric
- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project
sparks(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGcBAEBCgAGBQJSXAEzAAoJEB/kgVGp2CYvuYAL+wa2uxwCPazpIpFKjfO/WGIu
NmsWUw++BcdA5wBskvhS1vdC9tsI6Te5YpSkATcTk+iEoqvfZ0y84wFNJeL6i0N7
JHGgeU317kCJGjlRtGMvVlk8TrrUa4ICGrfu5At4CRCZSqr9cGgLp7eJTx7fMP+G
k5nqDXsPeWFXkLfyQJejgcsdoP3jxZA883VWZDsUWJ3Bow0Oj0n979pCJwKd3ZBE
N66ibYmCX97r1W6MB+g8bnORhvNo4UlhU0CNoViV0t7ffZpX9ZpRYdu+uYgwK1Jd
aCSk8MQCYX5RHo5yYFcd1NiQTXxiZINwQqTV2Y1RBrFOE09gfPhrVp2wHdDqihJq
VteGiDk+nHbOaiHYq0LG1d+qK7EZEa4XMf8EpZJsEs8lk921+zcBmT6JxtdxK9IX
siBUf8MQV+5CkBArjtTumActdYmVJzt8Ao1NIaBuL7oDK7XsX9MaUhTebPcIzHcl
3kyMwNFrSCkgGYTAxapjbgrf5RWN8HqhoiR0Rl9LFA==
=yRrn
-----END PGP SIGNATURE-----
3:33 p.m.
On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
<sparks(a)fedoraproject.org> wrote:
I believe he is assuming that xchat has a direct relationship with bluez which,
I'm guessing here as I haven't checked, probably isn't the case.
Because bluez affects something that xchat depends on xchat is getting thrown
into the pile of things that will break without bluez. Dependencies aren't
always 1:1...
Yes, I understand that Xchat is not directly dependent on bluez; It is being a victim
of associative dependency, something like
bluez <= gnome-bluetooth(libgnome-bluetooth-applet.so.0) <= gnome-shell <=
libnotify.so.4 <= xchat
My original question was if this is due to a packaging error or if yum's dependency
resolving algorithm is at fault. Because with remove_leaf_only=1, if you try to remove
individual packages,
# yum remove bluez,
# yum remove gnome-bluetooth
# yum remove pulseaudio-module-bluetooth
None of them work. But if you try to remove all 3 together
# yum remove gnome-bluetooh bluez pulseaudio-module-bluetooth
Yum prompts you to remove bluez ->
https://lists.fedoraproject.org/pipermail/devel/2013-October/190101.html
---
Regards
-Prasad
http://feedmug.com
2:20 a.m.
On 15. 10. 2013 at 04:33:08, P J P wrote:
> On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
> <sparks(a)fedoraproject.org> wrote: I believe he is assuming that xchat has
> a direct relationship with bluez which, I'm guessing here as I haven't
> checked, probably isn't the case. Because bluez affects something that
> xchat depends on xchat is getting thrown into the pile of things that
> will break without bluez. Dependencies aren't always 1:1...
Yes, I understand that Xchat is not directly dependent on bluez; It is
being a victim of associative dependency, something like
bluez <= gnome-bluetooth(libgnome-bluetooth-applet.so.0) <= gnome-shell <=
libnotify.so.4 <= xchat
My original question was if this is due to a packaging error or if yum's
dependency resolving algorithm is at fault. Because with
remove_leaf_only=1, if you try to remove individual packages,
# yum remove bluez,
# yum remove gnome-bluetooth
# yum remove pulseaudio-module-bluetooth
None of them work. But if you try to remove all 3 together
# yum remove gnome-bluetooh bluez pulseaudio-module-bluetooth
Yum prompts you to remove bluez ->
https://lists.fedoraproject.org/pipermail/devel/2013-October/190101.html
Yum's behavior is absolutely correct, it even reports you reasons why it
doesn't uninstall individual packages (in general none of them is a leaf
package).
In this particular case the problem is also the circular dependency between
bluez and gnome-bluetooth [1]. At this point I'm not sure about pulseaudio-
module-bluetooth but I suspect something similar going on there.
Even though yum might handle the resolution a little better (and dnf probably
will do that, feel free to check it), the ultimate culprit here is a very poor
packaging and both dnf and yum have only a limited set of options what to do
in such cases. Usually both do the right thing, as yum did in this case.
Thanks
Jan
[1]
$ repoquery --whatrequires gnome-bluetooth | grep bluez | tail -n 1
bluez-0:4.101-9.fc19.x86_64
$ repoquery --whatrequires bluez | grep gnome-bluetooth | tail -n 1
gnome-bluetooth-1:3.8.2.1-1.fc19.x86_64
6:56 a.m.
On Tuesday, 15 October 2013 12:51 PM, Jan Zelený
<jzeleny(a)redhat.com> wrote:
Even though yum might handle the resolution a little better (and dnf probably
will do that, feel free to check it), the ultimate culprit here is a very poor
packaging and both dnf and yum have only a limited set of options what to do
in such cases.
Yeah, true.
---
Regards
-Prasad
http://feedmug.com
noon
On 10/12/2013 09:42 AM, P J P wrote:
=======================================================================================
Package Arch Version
Repository Size
=======================================================================================
Removing:
bluez x86_64 4.101-9.fc19
@updates 1.9 M
Transaction Summary
=======================================================================================
Remove 1 Package
Installed size: 1.9 M
Is this ok [y/N]: N
===
If there's a bug, then this is it. You should not be able to remove
bluez because there are dependencies on it. Somehow, the combination of
options you've used confused yum.
12:11 p.m.
On Saturday, 12 October 2013 10:31 PM, Samuel Sieb
<samuel(a)sieb.net> wrote:
If there's a bug, then this is it. You should not be able to remove bluez because
there are dependencies on it.
Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes only, that is
why it allows removing bluez.
---
Regards
-Prasad
http://feedmug.com
12:14 p.m.
On 10/12/2013 10:11 AM, P J P wrote:
> On Saturday, 12 October 2013 10:31 PM, Samuel Sieb
<samuel(a)sieb.net> wrote:
> If there's a bug, then this is it. You should not be able to remove bluez
because there are dependencies on it.
Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes only, that
is why it allows removing bluez.
Seems like a really dangerous option then. If you actually went ahead
with that removal then you're probably going to get yum errors every
time you use it now.
1:20 p.m.
On Sun, Oct 13, 2013 at 00:42:43 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
It is an often experience that I try to remove a package(ex: bluez, kernel,
gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical
packages, which has no connection(ex. kernel => Xchat OR bluez => gedit etc.) with
the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf,
which should help remove only the leaf node packages and nothing else. So I set it.
The connection may not be obvious to you, but it's there. You shouldn't ever
remove kernel. You may want to remove a specific kernel (that you are't
currently running), but then you need to include a version number.
1:32 p.m.
Am 12.10.2013 20:20, schrieb Bruno Wolff III:
On Sun, Oct 13, 2013 at 00:42:43 +0800,
P J P <pj.pandit(a)yahoo.co.in> wrote:
>
> It is an often experience that I try to remove a package(ex: bluez, kernel,
gnome-bluetooth) and yum(8) prompts
> me to remove nearly 200-300MB worth of critical packages, which has no connection(ex.
kernel => Xchat OR bluez
> => gedit etc.) with the package I want to remove. Recently I was told to set
remove_leaf_only=1 in yum.conf,
> which should help remove only the leaf node packages and nothing else. So I set it.
The connection may not be obvious to you, but it's there. You shouldn't ever
remove kernel. You may want to remove
a specific kernel (that you are't currently running), but then you need to include a
version number.
wrong
"yum remove kernel" is uninstalling any *not running* kernel and if someone
has not messed up his installation will never remove any ther package
more true is that "yum remove kernel" is the way to go if you
increased the amount of kernel-versions to preserve
and want get rid of them all at once and keep only the running
3843
days inactive
3846
days old
28 comments
6 participants
participants (6)
-
Bruno Wolff III -
Eric Christensen -
Jan Zelený -
P J P -
Reindl Harald -
Samuel Sieb