Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#46526 - Pacman fails to recognize the correct order of package installation when downgrading.
Attached to Project:
Pacman
Opened by Vasil Yonkov (spirtbrat) - Friday, 02 October 2015, 09:13 GMT
Last edited by Allan McRae (Allan) - Sunday, 18 October 2015, 01:31 GMT
Opened by Vasil Yonkov (spirtbrat) - Friday, 02 October 2015, 09:13 GMT
Last edited by Allan McRae (Allan) - Sunday, 18 October 2015, 01:31 GMT
|
DetailsTake the following scenario:
-- installed are: glibc-2.22-1 binutils 2.25.1-2 depends on glibc>=2.22 -- I'm trying to downgrade 'glibc', along with 'binutils' to versions: glibc-2.21-4 binutils 2.25.1-1 depends on glibc>=2.20 On the command line both packages are arguments to 'sudo pacman -U ' when 'glibc' is first and 'binutils' is after it. Pacman correctly sees that after the transaction 'binutils' won't be broken, because it is also downgraded. What pacman fails to see is that 'binutils' should be downgraded *before* glibc. What happens is 'glibc' is downgraded, which actually breaks the binaries from the newer 'binutils' and now not only the second package can't be installed, but the whole system is ****ed :) |
This task depends upon
error: failed to prepare transaction (could not satisfy dependencies)
:: gcc-libs: requires glibc>=2.22
What did you do to work around this? Used -d?
What is happening is many, many binaries on your system will require at least the glibc version they were built with to be on the system. Downgrading glibc breaks stuff and should never be done.
and downgraded to it first.
I didn't mention it, because it doesn't really play a role in the
example that fails.
(1/2) downgrading glibc [######################] 100%
(2/2) downgrading binutils [######################] 100%
[root@allan pkg]# pacman -U glibc-2.21-4-i686.pkg.tar.xz binutils-2.25.1-1-i686.pkg.tar.xz
(1/2) downgrading glibc [######################] 100%
(2/2) downgrading binutils [######################] 100%
So two things:
1) This worked...
2) pacman orders the packages like this because binutils depends on glibc. The versions are correctly satisfied at the end of the transaction.
Pacman is working as expected.
all the things I do on my machine. You can pass a million packages as
arguments (well, maybe not a million), but as long as foo is before bar
and bar has a dependency on a version range of foo which will not be
satisfied after foo is installed and bar isn't yet, there will be a
moment of having an installed package with unsatisfied dependency. To
avoid it, pacman should change the order of package installation, so bar
is installed before foo (even within a transaction with a million
packages).
Now foo and bar are updated such that: foo-2-1 depends on bar=2-1.
Now what order should they be installed so that foo and bar always have their dependencies satisfied. Or should pacman just install bar then foo (as it currently does). There are many cases where packages should be installed in their future dependency order to avoid breakages.
And your breakage has nothing to do with the order pacman installed things...