Arch Linux

Unfortunately changing systemd to a runtime dependency introduces circular dependencies and results in tons of the following pacman warnings:

warning: dependency cycle detected:
warning: filesystem will be installed before its glibc dependency
warning: dependency cycle detected:
warning: ncurses will be installed before its glibc dependency
warning: dependency cycle detected:
warning: ncurses will be installed before its glibc dependency
warning: dependency cycle detected:
warning: lib32-glibc will be installed before its glibc dependency
warning: dependency cycle detected:
warning: filesystem will be installed before its glibc dependency

The fileystem/glibc one is printed way too many times.

The above is reproducible on a system using [testing] by doing 'pacman -S glibc filesystem'.

is the right way to fix that is to remove the deps in filesystem and add systemd to base-devel?

Possibly! @Dave @Christian thoughts?

I think I introduced this by changing device-mapper's dependency from systemd to libsystemd [0] to resolve a circular dependency. I am fine with adding systemd to base-devel. We had it in there before by dependency.

[0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lvm2&id=892ad7d0314d5d97d434c4f1fdf1095a28f997ed

I'm bumping a version of systemd in testing with groups=('base-devel') to check it solves this properly.

While having systemd in base-devel solves build issues for required users/groups how should we deal with runtime dependency?
We have to deal with two cases: either systemd itself has to create a certain user/group or some package provides a sysuser.d/foo.conf file that depends on the systemd sysuser hook.

We can either put for all these packages "systemd" to their runtime depenency or be honest and put systemd into "base" group and expect it to be installed on every Arch system.
I'm for the 2nd choice to put it into base group because we officially don't support any other init system and truely depend more and more on systemd functions. I guess it would still allow
to have users use a different init system of their choice as long as it is allowed to be installed along systemd.

But probably such a major decission should be brought to our public dev list.

Both actions should have been discussed on our mailing list. All recent changes to filesystem package went mostly unnoticed because not even half of the team tracks every single issue, and let's be honest, most of these changes are significant and had impact on other parts of distribution. No amount of sudden devtools changes or additions to base groups will change it.

Andreas, systemd is already in base group, via systemd-sysvcompat. Arch Linux iso and boostrap tarball both have systemd installed.
But devtools use base-devel, which prevent linux or others packages to be pulled to only build packages. Sure let's disuss it on dev public, maybe there is better options.

@Bartłomiej: Changes doesn't looks significant to me. I not see much difference with your statement of dropping nss_compat in glibc ( FS#54592 ), but I note your concern. Let's discuss it on a-d-p.
But I'm sad that you see «sudden» changes as something negative, where I tried to not let a broken situation in testing. Not to mention that:
- I did modification in systemd after receive a positive answer from one maintainer;
- I had proposed a solution in a bug report ( FS#55482 ) opened by the devtools maintainer 2 days before sending a patch to review in arch-projects and then 5 more days before merging it.