I see that dnf, in its infinite wisdom, has classified ignoring packages it can't find as a bug, therefore if you say
dnf install `cat f22-missing.txt`
to install as much stuff as possible in your new f22 as you used to have in f20, it will find the very first missing rpm (and ONLY the first), tell you it isn't in the repos, and quit.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1224485
So you delete it from the list and try again, which let's you find the 2nd one, repeat for several weeks, or discover there is a yum-deprecated out there and run:
yum-deprecated install `cat f22-missing.txt`
which will actually install everything it can and ignore the ones it can't find, thus saving you many hours of fixing the list or installing one package at a time with dnf.
On 18. 7. 2015 at 17:59:49, Tom Horsley wrote:
I see that dnf, in its infinite wisdom, has classified ignoring packages it can't find as a bug, therefore if you say
dnf install `cat f22-missing.txt`
to install as much stuff as possible in your new f22 as you used to have in f20, it will find the very first missing rpm (and ONLY the first), tell you it isn't in the repos, and quit.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1224485
So you delete it from the list and try again, which let's you find the 2nd one, repeat for several weeks, or discover there is a yum-deprecated out there and run:
yum-deprecated install `cat f22-missing.txt`
which will actually install everything it can and ignore the ones it can't find, thus saving you many hours of fixing the list or installing one package at a time with dnf.
IIRC this feature is on the roadmap and should be implemented in a matter of weeks.
Thanks Jan
I'm with Jan...Thank God for yum-deprecated. Been trying to get systemd updated with DNF forever and it's been throwing an error about fedora-release..yum-deprecated has it handled. The whole skip-broken part of yum makes it so much easier to actually do updates. DNF's handling of broken packages by stopping the update cold is worthless.
My $.02.
Kevin
On Mon, Jul 20, 2015 at 2:00 AM, Jan Zelený jzeleny@redhat.com wrote:
On 18. 7. 2015 at 17:59:49, Tom Horsley wrote:
I see that dnf, in its infinite wisdom, has classified ignoring packages it can't find as a bug, therefore if you say
dnf install `cat f22-missing.txt`
to install as much stuff as possible in your new f22 as you used to have in f20, it will find the very first missing rpm (and ONLY the first), tell you it isn't in the repos, and quit.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1224485
So you delete it from the list and try again, which let's you find the 2nd one, repeat for several weeks, or discover there is a yum-deprecated out there and run:
yum-deprecated install `cat f22-missing.txt`
which will actually install everything it can and ignore the ones it can't find, thus saving you many hours of fixing the list or installing one package at a time with dnf.
IIRC this feature is on the roadmap and should be implemented in a matter of weeks.
Thanks Jan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 20. 7. 2015 at 08:57:41, kevin martin wrote:
I'm with Jan...Thank God for yum-deprecated. Been trying to get systemd updated with DNF forever and it's been throwing an error about fedora-release..yum-deprecated has it handled. The whole skip-broken part of yum makes it so much easier to actually do updates. DNF's handling of broken packages by stopping the update cold is worthless.
Well, I can't be sure because you haven't provided any details but it sounds like something --best might be able to solve for you.
Thanks Jan
On Mon, Jul 20, 2015 at 16:02:11 +0200, Jan Zelený jzeleny@redhat.com wrote:
On 20. 7. 2015 at 08:57:41, kevin martin wrote:
I'm with Jan...Thank God for yum-deprecated. Been trying to get systemd updated with DNF forever and it's been throwing an error about fedora-release..yum-deprecated has it handled. The whole skip-broken part of yum makes it so much easier to actually do updates. DNF's handling of broken packages by stopping the update cold is worthless.
Well, I can't be sure because you haven't provided any details but it sounds like something --best might be able to solve for you.
That doesn't really help much. It provides some data on why it isn't doing things that might allow you to figure out how to modify the command to get it to partially succeed. --allowerasing only works in some cases and I haven't been able to figure out which cases.
For just doing updates (not installs) I found that dnf does a better job at figuring out what can be updated without removing anything. Yum's depsolver would just give up in some caes where dnf can do some updates.
On 20. 7. 2015 at 10:12:35, Bruno Wolff III wrote:
On Mon, Jul 20, 2015 at 16:02:11 +0200,
Jan Zelený jzeleny@redhat.com wrote:
On 20. 7. 2015 at 08:57:41, kevin martin wrote:
I'm with Jan...Thank God for yum-deprecated. Been trying to get systemd updated with DNF forever and it's been throwing an error about fedora-release..yum-deprecated has it handled. The whole skip-broken part of yum makes it so much easier to actually do updates. DNF's handling of broken packages by stopping the update cold is worthless.
Well, I can't be sure because you haven't provided any details but it sounds like something --best might be able to solve for you.
That doesn't really help much. It provides some data on why it isn't doing things that might allow you to figure out how to modify the command to get it to partially succeed. --allowerasing only works in some cases and I haven't been able to figure out which cases.
For just doing updates (not installs) I found that dnf does a better job at figuring out what can be updated without removing anything. Yum's depsolver would just give up in some caes where dnf can do some updates.
That's basically what --allowerasing is about. The idea is that when you run upgrade, you most likely don't want this upgrade to remove any of the packages that are currently installed on your system. As the name says, the -- allowerasing switch removes this assumption, allowing the dependency solver to have more available solutions to choose from.
Let me give you an example how can such situation occur. You install package A which it depends on a certain capability that packages B and C provide. The dependency solver chooses to install package C and finishes the transaction. Then, after some time, package A gets an upgrade that requires newer version of the aforementioned functionality. However, package C doesn't provide this newer version. An intuitive solution is to remove package C and install package B instead. To do that you need to use --allowerasing, as dnf doesn't expect you by default to want a solution that includes removing currently installed package.
Back to your original question, I am not sure what the problem is. You seem to describe a situation where package has some broken deps and therefore can't be installed in which case it is not going to be installed, neither by yum nor by dnf and --skip-broken will have no effect on that. Or am I missing something?
HTH Jan
On Mon, Jul 20, 2015 at 17:35:18 +0200, Jan Zelený jzeleny@redhat.com wrote:
That's basically what --allowerasing is about. The idea is that when you run upgrade, you most likely don't want this upgrade to remove any of the packages that are currently installed on your system. As the name says, the -- allowerasing switch removes this assumption, allowing the dependency solver to have more available solutions to choose from.
But it doesn't always remove packages that would allow upgrading another package. The documentation doesn't appear to give precise information about when packages will be erased in order to allow upgrades. The case where I'd like to see it work is when there is a soname bump, but not all dependencies have been updated yet. In most cases I prefer to remove the unupdated packages temporary so that I can use the latest version of the library. It would also be useful for upograding between Fedora releases where retired packages can also block library updates.
Back to your original question, I am not sure what the problem is. You seem to describe a situation where package has some broken deps and therefore can't be installed in which case it is not going to be installed, neither by yum nor by dnf and --skip-broken will have no effect on that. Or am I missing something?
There are cases where yum gets to a point where it won't do any installs or updates, even though --skip-broken is turned on and some installs or updates are possible. You can work around this by trying to update or install a smaller set of packages. For updates dnf is better, but for installs it is currently worse.
----- Original Message -----
From: "Bruno Wolff III" bruno@wolff.to To: "Jan Zelený" jzeleny@redhat.com Cc: users@lists.fedoraproject.org Sent: Monday, July 20, 2015 5:54:34 PM Subject: Re: Thank God for yum-deprecated :-)
On Mon, Jul 20, 2015 at 17:35:18 +0200, Jan Zelený jzeleny@redhat.com wrote:
That's basically what --allowerasing is about. The idea is that when you run upgrade, you most likely don't want this upgrade to remove any of the packages that are currently installed on your system. As the name says, the -- allowerasing switch removes this assumption, allowing the dependency solver to have more available solutions to choose from.
But it doesn't always remove packages that would allow upgrading another package. The documentation doesn't appear to give precise information about when packages will be erased in order to allow upgrades. The case where I'd like to see it work is when there is a soname bump, but not all dependencies have been updated yet. In most cases I prefer to remove the unupdated packages temporary so that I can use the latest version of the library. It would also be useful for upograding between Fedora releases where retired packages can also block library updates.
Right, it still does not allow the depsolver to remove a capability at all. It allows it only to replace a package which provides a required capability with another package which provides it as well.
Back to your original question, I am not sure what the problem is. You seem to describe a situation where package has some broken deps and therefore can't be installed in which case it is not going to be installed, neither by yum nor by dnf and --skip-broken will have no effect on that. Or am I missing something?
There are cases where yum gets to a point where it won't do any installs or updates, even though --skip-broken is turned on and some installs or updates are possible. You can work around this by trying to update or install a smaller set of packages. For updates dnf is better, but for installs it is currently worse. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Tue, Jul 21, 2015 at 11:32:58 -0400, Radek Holy rholy@redhat.com wrote:
Right, it still does not allow the depsolver to remove a capability at all. It allows it only to replace a package which provides a required capability with another package which provides it as well.
Can you describe this more precisely? Packages still provide themselves and the installed files and these don't seem to be locked down. Is this limited to explicit provides? And/or perhaps the automatic soname provides?
----- Original Message -----
From: "Bruno Wolff III" bruno@wolff.to To: "Radek Holy" rholy@redhat.com Cc: "Community support for Fedora users" users@lists.fedoraproject.org Sent: Tuesday, July 21, 2015 11:20:02 PM Subject: Re: Thank God for yum-deprecated :-)
On Tue, Jul 21, 2015 at 11:32:58 -0400, Radek Holy rholy@redhat.com wrote:
Right, it still does not allow the depsolver to remove a capability at all. It allows it only to replace a package which provides a required capability with another package which provides it as well.
Can you describe this more precisely? Packages still provide themselves and the installed files and these don't seem to be locked down. Is this limited to explicit provides? And/or perhaps the automatic soname provides?
Hm, it seems that I was too tired yesterday :( It really allows the solver to remove any package in order to fulfil the given request. Sorry for the noise :(
If it does not work in some cases, I believe we can collaborate with libsolv authors to find out the reason.
The most precise description is that it sets the SOLVER_FLAG_ALLOW_UNINSTALL flag which is described here: https://github.com/openSUSE/libsolv/blob/master/doc/libsolv-bindings.txt#L20...
Sorry :(
On Wed, Jul 22, 2015 at 04:22:13 -0400, Radek Holy rholy@redhat.com wrote:
The most precise description is that it sets the SOLVER_FLAG_ALLOW_UNINSTALL flag which is described here: https://github.com/openSUSE/libsolv/blob/master/doc/libsolv-bindings.txt#L20...
I looked through that and it isn't easy to understand, but I have a theory what might be happening that I test after the next set of rawhide updates with a soname bump that does cover anything.
My theory is that since I am not listing any specific packages to update, it is acting as an upgrade all packages and locking in all installed packages and in effect making --allowerasing moot. My plan is when I see a warning about a case of interest is to then try to specifically update the library with --allowerasing and see what happens.
-
Bruno Wolff III -
Jan Zelený -
kevin martin -
Radek Holy -
Tom Horsley