Pacman

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.
Tasklist

FS#54729 - [pacman] pacman should respect command line package order for dependency cycle

Attached to Project: Pacman
Opened by AMM (amish) - Friday, 07 July 2017, 01:31 GMT
Last edited by Andrew Gregory (andrewgregory) - Friday, 07 July 2017, 15:54 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Recently there was a bug introduced where systemd and cryptsetup had dependency cycle, which caused "FRESH" Arch linux installation to fail.

cryptsetup --> device-mapper --> systemd --> cryptsetup

pacman decided to install systemd first and since systemd post install scripts depended on libcryptsetup.so.4, they all FAILED and the Arch linux installation used to fail OR be incomplete.

Please refer to this thread for more details:
https://bbs.archlinux.org/viewtopic.php?pid=1722733#p1722733

The issue was resolved later on. But because of this many administrators had to wait 2days for their installation.

This issue may come again future for any package.

Additional info:
* package version(s)
Any version

Steps to reproduce:
pacstrap /mnt base

Possible solution:
The solution is that pacman continues existing logic but command line package order gets the priority for dependency cycle.

For example, to workaround above problem I could have given this command to inform pacman to install crypsetup first
pacstrap /mnt base cryptsetup systemd

base has both cryptsetup and systemd and pacman would first detect dependency cycle and pick systemd first. But then it can check that command line where cryptsetup is first, so it should change the order to:
device-mapper, cryptsetup, systemd

This logic should be applied in case of dependency cycle only.

Hope I make sense here.
This task depends upon

Closed by  Andrew Gregory (andrewgregory)
Friday, 07 July 2017, 15:54 GMT
Reason for closing:  None
Additional comments about closing:  Dependency resolution order can already be influenced by specifying arguments in the correct order.
Comment by Dave Reisner (falconindy) - Friday, 07 July 2017, 01:44 GMT
If you know ahead of time that you're about to encounter a dependency cycle, you have other means of fixing (after the fact) whatever it is which is broken by said dependency cycle.
Comment by AMM (amish) - Friday, 07 July 2017, 02:57 GMT
How to fix a core package while doing pacstrap? Because pacman simply picks and installs "BAD" core package from Arch mirrors.

I could solve it by making my own repo and putting my own "CORRECT" package in it. But thats not always practical.

That is why there should be way to tell pacman that - "Hey - there is problem here, which is currently beyond my control, and hence this is the order you need to pick"
Comment by Andrew Gregory (andrewgregory) - Friday, 07 July 2017, 03:25 GMT
You can already influence package installation order for cycles, it just goes the other way. The package given first has its dependencies resolved first, so they get installed before it.
Comment by AMM (amish) - Friday, 07 July 2017, 03:51 GMT
No it didnt work that way, I had tried
pacstrap /mnt cryptsetup base

It didnt work... pacman said... Ignoring cryptsetup

And hence this bug/feature request.
Comment by Andrew Gregory (andrewgregory) - Friday, 07 July 2017, 05:15 GMT
Like I said, the package given first has its dependencies resolved first. If you list cryptsetup first, it will pull in systemd as a dependency, installing systemd before cryptsetup. What you should have run is `pacstrap /mnt systemd base`.
Comment by AMM (amish) - Friday, 07 July 2017, 05:56 GMT
Ok I misunderstood your previous suggestion. But unfortunately now I can not test that anymore as package that had this issue has resolved the issue. Will have to wait till pacman reports another dependency cycle.

Also just for the record. I would also like to suggest alternate solutions.

In case of dependency cycle:

Solution 1)
Install files of the all packages first and then run their post-install / upgrade scripts. If package has preinstall script run that just before installing that package.

For example: Package A, B have dependency cycle. Then run in this fashion
a) Preinstall/preupgrade of A
b) Install/upgrade A
c) Preinstall/preupgrade of B
d) Install/upgrade B
e) Postinstall/postupgrade of A
f) Postinstall/postupgrade of B

This may require lot of changes to pacman code.

OR

Solution 2)
Give priority to package that does not have "install" file to package that has one. And install in same way as pacman does currently (just that order of installation will alter a bit)

This would require only slight change in "_alpm_sortbydeps()" (provided that function has way to know if package has install file or not)

Both solutions should atleast make sure that "install" scripts find the files that they are looking for.
Comment by Andrew Gregory (andrewgregory) - Friday, 07 July 2017, 14:12 GMT
There are other dependency cycles you can test with, freetype2 and harfbuzz for instance.
Comment by AMM (amish) - Friday, 07 July 2017, 15:43 GMT
Oh great! Didnt know about them as they dont get installed with base group installation.

Just tested it, perfect, works as expected.

Here is the TIP for those who come across such situation in future:

I was trying this:
pacstrap /mnt base cryptsetup systemd
OR
pacstrap /mnt base systemd cryptsetup

But correct way to do it is to put them before base group like this:
pacstrap /mnt systemd cryptsetup base
OR, just
pacstrap /mnt systemd base

So cryptsetup will be installed first and then systemd.

If you put them after base group, pacman does not change the order. (because pacman ignores remaining arguments as they are already part of base group)

Thank you. Requesting closure.

Loading...