I am trying to upgrade to F23 (I know still not finished but...)
In past I always done 'distro-sync'. Albeit with yum.
Now I tried: dnf system-upgrade download --releasever=23 --distro-sync dnf system-upgrade download --releasever=23 --distro-sync --best dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing
And all of them fail. See below for full log.
On the other hand: dnf system-upgrade download --releasever=23 succeed.
Actually most of the problem are caused by retired or obsoleted packages. E.g fedup-dracut or rubygem-celluloid (this one reported as BZ 1275030).
My question is should we use --distro-sync at all? Are users supposed to remove obsoleted packages manually?
If I do not pass --distro-sync then some packages are not upgraded. E.g in my case after upgrade I have grub2-tools-2.02-0.16.fc22.x86_64.
Full log of failures.
# dnf system-upgrade download --releasever=23 --distro-sync --best cannot install both kernel-devel-4.2.3-300.fc23.x86_64 and kernel-devel-3.19.4-200.fc21.x86_64. package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed. package rpm-libs-4.12.0.1-12.fc22.x86_64 requires rpm = 4.12.0.1-12.fc22, but none of the providers can be installed (try to add '--allowerasing' to command line to replace conflicting packages)
# dnf system-upgrade download --releasever=23 --distro-sync Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package grub2-tools-1:2.02-0.23.fc23.x86_64 requires librpm.so.7()(64bit), but none of the providers can be installed (try to add '--allowerasing' to command line to replace conflicting packages)
# dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed
On Mon, Oct 26, 2015 at 06:24:43PM +0100, Miroslav Suchý wrote:
I am trying to upgrade to F23 (I know still not finished but...)
In past I always done 'distro-sync'. Albeit with yum.
Now I tried: dnf system-upgrade download --releasever=23 --distro-sync dnf system-upgrade download --releasever=23 --distro-sync --best dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing
And all of them fail. See below for full log.
On the other hand: dnf system-upgrade download --releasever=23 succeed.
Actually most of the problem are caused by retired or obsoleted packages. E.g fedup-dracut or rubygem-celluloid (this one reported as BZ 1275030).
FTR, fedup-dracut was obsoleted today morning (https://bugzilla.redhat.com/show_bug.cgi?id=1275085).
My question is should we use --distro-sync at all? Are users supposed to remove obsoleted packages manually?
--distro-sync is now (in git, I don't think this version was released yet) the default in dnf-plugin-system-upgrade.
# dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed
What version of dnf/libsolv are you using? The last update (libsolv-0.6.14-2.fc22,dnf-1.1.3-1.fc22) solved a bunch of upgrade problems.
Zbyszek
Dne 26.10.2015 v 18:39 Zbigniew Jędrzejewski-Szmek napsal(a):
--distro-sync is now (in git, I don't think this version was released yet) the default in dnf-plugin-system-upgrade.
OK. So I will file BZs for all issues I find with --distro-sync I hit.
# dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed
What version of dnf/libsolv are you using? The last update (libsolv-0.6.14-2.fc22,dnf-1.1.3-1.fc22) solved a bunch of upgrade problems.
Exactly dnf-1.1.3-1.fc22
You have a chance to get your rpmfusion softwares wiped after the sync.
[1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
Am 29.10.2015 um 10:09 schrieb Christopher Meng:
You have a chance to get your rpmfusion softwares wiped after the sync.
unacceptable
the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"
in the past you saw *exactly* which package requires which so-version and so find out where the problem starts, which packages you may consider to remove and then try again
currently we have some sort of blackbox with no output how to solve dependency problems
On 10/29/2015 05:56 AM, Reindl Harald wrote:
the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"in the past you saw *exactly* which package requires which so-version and so find out where the problem starts, which packages you may consider to remove and then try again
currently we have some sort of blackbox with no output how to solve dependency problems
I believe "dnf update --best" is more verbose and tells you where conflict is coming from. This is not very discoverable; I can't remember how I arrived at trying --best, but it probably should be the default, as you say.
On Thu, Oct 29, 2015 at 5:56 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 29.10.2015 um 10:09 schrieb Christopher Meng:
You have a chance to get your rpmfusion softwares wiped after the sync.
unacceptable
the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"
in the past you saw *exactly* which package requires which so-version and so find out where the problem starts, which packages you may consider to remove and then try again
currently we have some sort of blackbox with no output how to solve dependency problems
Is there any reason you can't put that in the actual Bugzilla thread?
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
* system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
* change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
On Qui, 2015-10-29 at 13:44 +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
- system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
- change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
You need --allowerasing for updates which obsolete other packages, if not you can't update. distro-sync can downgrading packages which in upgrading is not the best place . You can do it after upgrade the system . dnf update --allowerasing is what I want /need .
Am 29.10.2015 um 14:11 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 13:44 +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
- system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
- change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
You need --allowerasing for updates which obsolete other packages, if not you can't update
what??????????????????????
that would be another regression compared to yum
distro-sync can downgrading packages which in upgrading is not the best place . You can do it after upgrade the system . dnf update --allowerasing is what I want /need
the whole purpose of distro-sync is that it can downgrade - as exmaple you may have stuff from updates-testing installed and updates-testing not enabled due distro-sync and so the versions in the newer release can be lower
the only right thing to do in that case is downgrade them, also for packages where maintainers just forgot to rebuild for the next release which happened often enough in the past
On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
- system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
- change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
There are three options: (1, no distro-sync) — upgrade only packages which can be upgraded without conflicts. Leaves a partially upgraded system in some cases. (2, distro-sync) — upgrade packages which can be upgraded, remove conflicting ones. Lose some packages during upgrade. (3, force) — upgrade all packages ignoring conflicts. Leaves the system with some programs broken.
You seem to dislike all the options, but I don't see anything else possible. Do you have some better proposal?
(Note that the user is always asked for confirmation before proceeding, so she can always stop to remove/update packages by hand in all three cases.)
Zbyszek
Am 29.10.2015 um 14:18 schrieb Zbigniew Jędrzejewski-Szmek:
On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
- system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
- change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
There are three options: (1, no distro-sync) — upgrade only packages which can be upgraded without conflicts. Leaves a partially upgraded system in some cases. (2, distro-sync) — upgrade packages which can be upgraded, remove conflicting ones. Lose some packages during upgrade. (3, force) — upgrade all packages ignoring conflicts. Leaves the system with some programs broken.
You seem to dislike all the options, but I don't see anything else possible. Do you have some better proposal?
just behave like "yum --releasever=XX distro-sync" all the years before and just REFUSE to upgrade if there are conflicts because anything else is undefined behavior
DNF just needs to give enough information how to solve the dependency problems
On Thu, Oct 29, 2015 at 02:20:50PM +0100, Reindl Harald wrote:
Am 29.10.2015 um 14:18 schrieb Zbigniew Jędrzejewski-Szmek:
On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
You have a chance to get your rpmfusion softwares wiped after the sync.
yep, so not distro-sync
nonsense when i read the bugreport
- system-upgrade now uses dnf (standard "dnf update" approach)
THAT is the problem and i really wonder what somebody thinks by implement it that way after *many years* of "yum --releasever=XX distro-sync" works absolutely relieable
- change "dnf update" mode during system upgrade to "dnf distro-sync --allowerasing"
THAT is the right direction but nonsense because --allowerasing is a terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected by both wrong solutions as far as i see (expect DNF is intentionally or unintenioally broken elsewhere there)
There are three options: (1, no distro-sync) — upgrade only packages which can be upgraded without conflicts. Leaves a partially upgraded system in some cases. (2, distro-sync) — upgrade packages which can be upgraded, remove conflicting ones. Lose some packages during upgrade. (3, force) — upgrade all packages ignoring conflicts. Leaves the system with some programs broken.
You seem to dislike all the options, but I don't see anything else possible. Do you have some better proposal?
just behave like "yum --releasever=XX distro-sync" all the years before and just REFUSE to upgrade if there are conflicts because anything else is undefined behavior
Well, that's what it does, more or less. Depending on --allowerasing being there or not, it asks or refuses. You can always say "no".
DNF just needs to give enough information how to solve the dependency problems
Yeah, it should. It's not too bad already.
Zbyszek
From: "Miroslav Suchý" msuchy@redhat.com
# dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed. package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed
What version of dnf/libsolv are you using? The last update (libsolv-0.6.14-2.fc22,dnf-1.1.3-1.fc22) solved a bunch of upgrade problems.
Exactly dnf-1.1.3-1.fc22
The distro-sync changes happened in libsolv-0.6.14-2 - it should be a requirement of dnf-plugin-system-upgrade-0.7.0.
You can exclude the conflicting packages to proceed the system-upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
From: "Reindl Harald" h.reindl@thelounge.net To: devel@lists.fedoraproject.org Sent: Thursday, October 29, 2015 10:56:47 AM Subject: Re: To distro-sync or not distro-sync?
From: "Reindl Harald" h.reindl@thelounge.net the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"
dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation of conflicting packages. Installing the packages regardless the dependencies by `--force` is really dangerous and will not be supported by DNF.
currently we have some sort of blackbox with no output how to solve dependency problems
It outputs the last package conflict found by depsolver. The improvement is on the agenda [1].
Honza
Am 29.10.2015 um 13:24 schrieb Honza Šilhan:
From: "Miroslav Suchý" msuchy@redhat.com From: "Reindl Harald" h.reindl@thelounge.net the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"
dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation of conflicting packages. Installing the packages regardless the dependencies by `--force` is really dangerous and will not be supported by DNF.
removing random packages is also really dangerous and *not* acceptable
frankly if there are problems and i need a hammer then i need a hammer in case i know what i am doing - i have solved yum distrupgrade troubles hundrets of times by "rpm -e --nodeps" for packages where i am 100% sure that they are not system critical and guess what - after that the deps where solved and even the correct dependencies installed without any cleanup needed after the upgrade
currently we have some sort of blackbox with no output how to solve dependency problems
It outputs the last package conflict found by depsolver. The improvement is on the agenda [1].
hopefully because https://bugzilla.redhat.com/show_bug.cgi?id=1148627#c27 is the truth until now
On Thu, Oct 29, 2015 at 01:33:45PM +0100, Reindl Harald wrote:
Am 29.10.2015 um 13:24 schrieb Honza Šilhan:
From: "Miroslav Suchý" msuchy@redhat.com From: "Reindl Harald" h.reindl@thelounge.net the software upgrade just have to mention the conflicting packages and stop until somebody enables a --force switch and in general DNF has to be much more verbose in case of dependency problems instead just saying "can't do anything because broken deps"
dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation of conflicting packages. Installing the packages regardless the dependencies by `--force` is really dangerous and will not be supported by DNF.
removing random packages is also really dangerous and *not* acceptable
frankly if there are problems and i need a hammer then i need a hammer in case i know what i am doing - i have solved yum distrupgrade troubles hundrets of times by "rpm -e --nodeps" for packages where i am 100% sure that they are not system critical and guess what - after that the deps where solved and even the correct dependencies installed without any cleanup needed after the upgrade
It asks for confirmation. The list of packages to remove is the last thing before the prompt... Those prompts could be made more visible, and/or we could make it easier to retrieve the list of removed packages after the installation is done, but that's about it.
Zbyszek
On 2015-10-29, Reindl Harald h.reindl@thelounge.net wrote:
removing random packages is also really dangerous and *not* acceptable
It does not remove random packages. It removes packages that are not needed because the package was not installed explicitly and it's not a transitive dependency of such explicitly installed package.
So either it's a bug in dependency specification, or the user should mark the package as explicitly wanted.
Frankly if someone do a mass upgrade, he should expect some changes.
A contraexemple: A package splits into more subpackages. Suddenly packages needing a moved file and requiring a package name instead of a file name will stop work.
Are we going to fight against splitting packages?
(Better distributions have system of notifications that allows to warn a user before the upgrade that something important is going to change.)
-- Petr
Petr Pisar wrote:
It does not remove random packages. It removes packages that are not needed because the package was not installed explicitly and it's not a transitive dependency of such explicitly installed package.
That's the autoremove misfeature, which is really a different issue than the --allowerasing to resolve dependency conflicts that is being discussed here.
IMHO, enabling autoremoval by default was a horrible idea.
Kevin Kofler
On 10/29/2015 08:33 AM, Reindl Harald wrote:
Am 29.10.2015 um 13:24 schrieb Honza Šilhan:
dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation of conflicting packages. Installing the packages regardless the dependencies by `--force` is really dangerous and will not be supported by DNF.
removing random packages is also really dangerous and *not* acceptable
For what it's worth, in the YUM days few years back I had a botched update (not even upgrade!). I believe it was a 5.x Centos, and yum decided to delete a ton of packages. The system became unbootable, and I had to do a lot of manual yum installs including IIRC yum itself, to restore it. I didn't even file yum bugs because that system has a rich history and a lot of odd software installed so I chalked it to 'self-inflicted', but:
I learned to be very careful reading the lists of packages suggested for deletion.
Am 29.10.2015 um 16:30 schrieb Przemek Klosowski:
On 10/29/2015 08:33 AM, Reindl Harald wrote:
Am 29.10.2015 um 13:24 schrieb Honza Šilhan:
dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation of conflicting packages. Installing the packages regardless the dependencies by `--force` is really dangerous and will not be supported by DNF.
removing random packages is also really dangerous and *not* acceptable
For what it's worth, in the YUM days few years back I had a botched update (not even upgrade!). I believe it was a 5.x Centos, and yum decided to delete a ton of packages. The system became unbootable, and I had to do a lot of manual yum installs including IIRC yum itself, to restore it. I didn't even file yum bugs because that system has a rich history and a lot of odd software installed so I chalked it to 'self-inflicted', but:
I learned to be very careful reading the lists of packages suggested for deletion
well, luckily we have now /etc/dnf/protected.d/dnf.conf containing "dnf" to prevent the combination of bugs and mistakes doing that sort of damage - i remember well summer 2014 how hard i was defended to demand get that back since yum had it for years
the same for uninstall the running kernel
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system-upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
Vít
On Thursday, 29 October 2015 at 15:00, Vít Ondruch wrote:
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system-upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
It doesn't, at least not in F21: https://bugzilla.redhat.com/show_bug.cgi?id=1238204
Regards, Dominik
From: "Vít Ondruch" vondruch@redhat.com
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system-upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
It should definitely honor excluded packages after restart. System-upgrade should apply packages that were resolved and downloaded by DNF. I don't know how exactly are packages installed / removed after restart (Will know). If you encounter this problem, please, report a bug for dnf-plugin-system-upgrade component.
Honza
From: "Vít Ondruch" vondruch@redhat.com
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system-upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
It should definitely honor excluded packages after restart. System-upgrade should apply packages that were resolved and downloaded by DNF. I don't know how exactly are packages installed / removed after restart (Will know). If you encounter this problem, please, report a bug for dnf-plugin-system-upgrade component.
To everyone who's experimenting with system-upgrade - please use the latest packages available in Bodhi: https://bodhi.fedoraproject.org/updates/?packages=dnf-plugin-system-upgrade
They contain number of fixes.
On Thu, 2015-10-29 at 15:00 +0100, Vít Ondruch wrote:
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system -upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
Actually, you're correct, the -x/--exclude settings are not currently propagated to the upgrade. I filed an issue on github to track that:
https://github.com/rpm-software-management/dnf-plugin-system-upgrade/ issues/29
I *can* add that to the State object that dnf system-upgrade uses to pass the --best/--allowerasing/etc. settings between the download and the upgrade, but I think the best long-term solution is for DNF to provide some .save()/.load() method(s) that will correctly save *all* the relevant configuration and transaction bits, rather than trying to figure all of this out on my own in an external plugin.
-w
Dne 30.10.2015 v 18:06 Will Woods napsal(a):
On Thu, 2015-10-29 at 15:00 +0100, Vít Ondruch wrote:
Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
You can exclude the conflicting packages to proceed the system -upgrade i.e.: "dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid --allowerasing"
Does the "-x" work actually? Last time I tried, the package I excluded was not downloaded (as expected), but after restart, the "-x" was not used and my system-upgrade failed (this was unexpected). These flags should be propagated and honored after restart, during the upgrade phase.
Actually, you're correct, the -x/--exclude settings are not currently propagated to the upgrade. I filed an issue on github to track that:
https://github.com/rpm-software-management/dnf-plugin-system-upgrade/ issues/29
Wonderful, thx for that.
Vít
I *can* add that to the State object that dnf system-upgrade uses to pass the --best/--allowerasing/etc. settings between the download and the upgrade, but I think the best long-term solution is for DNF to provide some .save()/.load() method(s) that will correctly save *all* the relevant configuration and transaction bits, rather than trying to figure all of this out on my own in an external plugin.
-w
-
Christopher Meng -
Dominik 'Rathann' Mierzejewski -
Honza Silhan -
Kamil Paral -
Kevin Kofler -
Miroslav Suchý -
Nico Kadel-Garcia -
Petr Pisar -
Przemek Klosowski -
Reindl Harald -
Sérgio Basto -
Vít Ondruch -
Will Woods -
Zbigniew Jędrzejewski-Szmek