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
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Eli Schwartz (eschwartz) - Thursday, 15 March 2018, 15:13 GMT
This would be zero maintenance I guess, and similar to gcc *an* argument could be made that separate components of a split package should never be able to be mismatched.

Idk.
Comment by Doug Newgard (Scimmia) - Thursday, 15 March 2018, 15:20 GMT
Very much of dubious value, as partial updates aren't supported. Versioned deps have a number of problems in Pacman, adding extra complexity here to prevent users from shooting themselves in the foot may not be worth it.
Comment by AMM (amish) - Thursday, 15 March 2018, 15:37 GMT
Well in that case why is there need to specify version dependencies in any package (even in postgresql or mariadb or gcc-lib)

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?
Comment by Doug Newgard (Scimmia) - Thursday, 15 March 2018, 15:40 GMT
It's not needed.
Comment by AMM (amish) - Thursday, 15 March 2018, 15:56 GMT
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mariadb&id=e1f328fd99b1819f34e8666f1dadc295779326cd

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?
Comment by Christian Hesse (eworm) - Thursday, 15 March 2018, 16:08 GMT
Some packages depend on the mariadb libraries, so this package is installed on a huge number of systems. Now users tend to install software without doing an update before or at the same time. This can result in mariadb being more recent than its libraries. Thus I added the explicit dependencies.
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.
Comment by AMM (amish) - Thursday, 15 March 2018, 16:19 GMT
"Now users tend to install software without doing an update before or at the same time"

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 :)
Comment by Toolybird (Toolybird) - Friday, 14 April 2023, 07:34 GMT
FWIW, I requested something similar for QEMU in  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.

Loading...