PMS says a package's DEPEND must be present at the time of merge, but it doesn't say that for RDEPEND. ulm dug up the following interesting changes over time to the phrasing in PMS: - https://gitweb.gentoo.org/proj/pms.git/commit/?id=f7028c2758d8da7c1339ba33d89d21b3e720e0bb - https://gitweb.gentoo.org/proj/pms.git/commit/?id=2f0989d0b6ee10d60593f4d800a1cf5b662f450f - https://gitweb.gentoo.org/proj/pms.git/commit/?id=b7079f361efcc44d774b525b8907ae8d1a329b27
We've had a note about this in the devmanual for a long time at https://devmanual.gentoo.org/general-concepts/dependencies/#runtime-dependencies: """ Items which are in RDEPEND but not DEPEND could in theory be merged after the target package. Portage does not currently do this. """ Prompted by spotting https://issuetracker.google.com/issues/283464020 (although the phrasing there might be slightly different to what we want?)
This seems like a bad idea to me. Despite what PMS says, there are likely packages that require the current behavior. And I think the current behavior makes more sense anyway. I think PMS should be updated, not Portage. For example, see bug 902207. There, we have acct-group packages which are in RDEPEND in acct-user packages. The groups MUST be merged before the users, or useradd will fail. Listing the acct-group packages in DEPEND is wrong, and will be ineffective for binpkg installations. Listing the acct-group packages in IDEPEND is wrong when BROOT != ROOT.
(In reply to Mike Gilbert from comment #2) > Listing the acct-group packages in IDEPEND is wrong when BROOT != ROOT. I'm sure that BROOT != ROOT is intended to work, but it's not at all clear to me that it does in fact work. If you install an acct-* package via RDEPEND such that it is satisfied in ROOT, this will not have any effect on commands from BROOT that see the account database in BROOT, and particularly it won't have any effect on portage itself when it merges the image. If you install an acct-* package via IDEPEND such that it is satisfied in BROOT, then it would (probably) affect /etc/passwd and image merging would correctly handle accounts except it ignores GLEP 81 overrides (we could solve this problem by finally abolishing overrides).
(In reply to Eli Schwartz from comment #3) I'm aware of that problem. However, the users created by acct-user packages are usually utilized by daemons at runtime, not by Portage at merge time, so it's often not a major issue in practice.
Ok but then those are perfectly fine to occur in any order as long as the resulting merge finishes off and all pending account management is completed, for example by running the sysusers.d processor for brand new accounts instead of useradd/groupadd to ensure "freshness" of accounts that are not ready yet.
(In reply to Eli Schwartz from comment #5) Sure, but said processing would need to occur after all necessary acct-* packages have been merge. Portage currently has no method for doing that.
The entire point of sysusers.d is to be idempotent so while it could be argued to be wasteful computing, there's no real downside to repeating it. It's possible to specify which dropin files to process, as well. So if one wanted, one could limit it to the file installed by the current package, plus the corresponding acct-user <--> acct-group file "if it already exists". Depending on merge order, the "wrong" one might run first, but the other would then always make up for it.
I'm not sure our sysusers.d files will operate correctly if a user gets created before its primary group. In any case, this was simply an example of a use case where merge order for RDEPEND matters. Yes we could probably work around this, but there are probably other examples I am unaware of.
Oh, I see what you mean: if we run systemd-sysusers after every acct-* package is merged it may fail a few times, but should eventually succeed after the last package is merged. Yeah, that could work. It does introduce a dependency on systemd-sysusers, to which users may object. I'm not terribly concerned about that.
