Debian_SuperUser
New Member
Just a fun experiment in which I want to download and install all the packages available in the repo on Arch Linux. I did pacman -S $(pacman -Slq), but that creates unresolvable conflict problems.
Can I install ALL the packages?
- Thread starter Debian_SuperUser
- Start date
Brickwizard
Well-Known Member
You can, but it's frowned upon as it puts excessive load on the servers, and the repositories contain both 32 and 64 bit apps which could be where you're getting your conflicts,
OP
Debian_SuperUser
New Member
I am not actually planning to install all of them. I probably don't even have that much storage. I just want to try to install them for fun. How can I get past the conflict problems?
Brickwizard
Well-Known Member
I never got that heavy into Arch, so I will point you to this article
OP
Debian_SuperUser
New Member
Using -Sw only downloads them but doesn't install them. And I cannot install normally because of the package conflicts.
Brickwizard
Well-Known Member
Perhaps @f33dm3bits will pop in later , he is better at arch than I
To resolve conflicts signaled by package managers, it depends partly on what the conflicts are.
If you show an actual conflict message from the package manager, then readers may be able to see a way through the problem.
An example of a common conflict is when a program, say one named XXX, needs a particular library version, but that library version cannot be installed because it will upgrade an earlier library version upon which a number of other packages on the system depend. The package manager therefore won't install the new library, but will complain about a conflict, and program XXX thus can't be installed.
There are few ways of dealing with this sort of conflict, some of which are unsatisfactory.
One way is to not install the program XXX, and wait for the existing programs that depend on the old version library to be upgraded to depend on the new library.
Another way is to delete the programs that depend on the old version library, and then install the new library which will allow the installation of program XXX. Then it may be possible to re-install some or all of the programs that were deleted. If too many programs, or important programs, depend exclusively on the old library, then it may not be viable to take this route.
Another solution is to unpack the new library package itself, create a sandbox, and create a pathway in the system with environment variables so that program XXX can be directed to use the new library, which can be installed outside the package management system. See here for something like that:
askubuntu.com
Basically, linux systems are a moving target in the sense that many packages are routinely upgraded by their developers, and/or maintainers, and come to depend on newer versions of other programs to take advantage of refinements or newer capabilities, and they are not all uniformly backwards compatible.
There are other sorts of conflicts which can be resolved more satisfactorily depending on what they are. A common case is where an upgrade or system modification proposes to remove a whole desktop environment like gnome. It's possible to allow the package manager to do that, but after the upgrade or modification to the system, to simply re-install gnome, or all the gnome packages that were removed to recover entirely from the situation.
If you wish to resolve conflicts, each particular case is probably best looked at individually to see if there's a way out of it.
If you show an actual conflict message from the package manager, then readers may be able to see a way through the problem.
An example of a common conflict is when a program, say one named XXX, needs a particular library version, but that library version cannot be installed because it will upgrade an earlier library version upon which a number of other packages on the system depend. The package manager therefore won't install the new library, but will complain about a conflict, and program XXX thus can't be installed.
There are few ways of dealing with this sort of conflict, some of which are unsatisfactory.
One way is to not install the program XXX, and wait for the existing programs that depend on the old version library to be upgraded to depend on the new library.
Another way is to delete the programs that depend on the old version library, and then install the new library which will allow the installation of program XXX. Then it may be possible to re-install some or all of the programs that were deleted. If too many programs, or important programs, depend exclusively on the old library, then it may not be viable to take this route.
Another solution is to unpack the new library package itself, create a sandbox, and create a pathway in the system with environment variables so that program XXX can be directed to use the new library, which can be installed outside the package management system. See here for something like that:
How to solve package conflicts?
I would like to install both packages libsigc++-2.0-0c2a and libsigc++-2.0-0v5 at the same time, in order to run certain software. Apparently, however, the packages are conflicting and sudo apt-...
askubuntu.com
Basically, linux systems are a moving target in the sense that many packages are routinely upgraded by their developers, and/or maintainers, and come to depend on newer versions of other programs to take advantage of refinements or newer capabilities, and they are not all uniformly backwards compatible.
There are other sorts of conflicts which can be resolved more satisfactorily depending on what they are. A common case is where an upgrade or system modification proposes to remove a whole desktop environment like gnome. It's possible to allow the package manager to do that, but after the upgrade or modification to the system, to simply re-install gnome, or all the gnome packages that were removed to recover entirely from the situation.
If you wish to resolve conflicts, each particular case is probably best looked at individually to see if there's a way out of it.
