FS#57853 - [systemd] libsystemd, systemd, systemd-sysvcompat should have "same" version dependency
Attached to Project:
Arch Linux
Opened by AMM (amish) - Thursday, 15 March 2018, 14:37 GMT
Last edited by Toolybird (Toolybird) - Friday, 14 April 2023, 07:34 GMT
Opened by AMM (amish) - Thursday, 15 March 2018, 14:37 GMT
Last edited by Toolybird (Toolybird) - Friday, 14 April 2023, 07:34 GMT
|
Details
Description:
Arch Forum link where related discussion took place: https://bbs.archlinux.org/viewtopic.php?id=235355 While I can understand that Arch linux is rolling release and partial updates are not supported and system should always have latest packages. There are cases where one needs to downgrade certain package because new version does not function as expected. Recently I had an issue with new version (v238) of systemd package and I downgraded it to older version. While doing so I realized that command I ran was just: pacman -U /var/cache/pacman/pkg/systemd-237.64-1-x86_64.pkg.tar.xz And pacman accepted it without any issue or complaints. It went completely out of my sight that I should also downgrade libsystemd and systemd-sysvcompat. This could have easily broken my system to an unbootable state because old version of systemd may not function with new version of libsystemd. And new version of systemd-sysvcompat may not function with old version of systemd Now I realized my mistake immediately but this may not be true for everyone, especially new Arch users. They would have no clue what went wrong / what did they do wrong and they may not even have internet connection to ask questions or download Live ISO to fix the problem. So my suggestion is that, since systemd is very important package (next after kernel) the "same" version inter-dependency between systemd, libsystemd and systemd-sysvcompat should also be set specifically in PKGBUILD. We already have other packages like gcc/gcc-libs, postgresql/postgresql-libs, mariadb/mariadb-libs where such "same or higher" version inter-dependencies are set. There are many other packages too. More discussion (with people with varying views) can be read at Arch forum discussion link above Additional info: * package version(s) Any version * config and/or log files etc. None Steps to reproduce: pacman -U /var/cache/pacman/pkg/systemd-237.64-1-x86_64.pkg.tar.xz Expected result: pacman should refuse to downgrade systemd (alone) reporting the dependency error, unless I also downgrade libsystemd, systemd-sysvcompat Possible solution: In PKGBUILD, set version too in depends() array of split packages. Something like this: depends=("libsystemd=$pkgver-$pkgrel") Please consider the feature request. Thank you |
This task depends upon
Closed by Toolybird (Toolybird)
Friday, 14 April 2023, 07:34 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
Friday, 14 April 2023, 07:34 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
Idk.
Because everyone is supposed to be in sync with latest versions that are in repositories so there would never be need to specify version in depends() for those packages either.
For e.g: If user installs mariadb (10.1.31) then he is obviously supposed to have mariadb-clients (10.1.31) because thats the only one in repositories. Why to mention same version dependency there?
See this for mariadb - they did it about 15 months back.
Done by eworm himself
Changelog:
* depend on exact version of split packages
So why did they do it? There must be reason?
With systemd the risk is not that huge - systemd is installed on most systems anyway. How ever wants to do package downgrades should know the possible results. I am not not sure we want this.
I did not understand this statement / situation completely. But this sounds like against what Scimmia wrote above.
He said:
" ... adding extra complexity here to prevent users from shooting themselves in the foot may not be worth it"
He also said:
"It's not needed." (in mariadb package as well)
So one Arch representative is wrong here.
And how is mariadb more important than systemd? How is breaking whole system less risky than breaking a database?
Anyway - I am fine with any outcome. I do not want to drag this in to discussion once again.
So requesting to please either accept it or close it. Smile :)
FS#75778, and it was implemented. The systemd PM has already stated back in 2018 the reasons against doing it here. We can always reconsider if someone finds a compelling enough reason.