Hm. Could the "traditional" setup be moved to a separate "old way to do things that you should not use anymore" page maybe? Similar to https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/. There's still many packages that use this, I don't think it would be good to drop the documentation for it entirely (yet).

It's certainly possible. I was hoping to avoid this, because of the reasons described above: to enable strict deps in rpm, we need to convert most packages. (Actually, any packages which provide files owned by users/groups.) And we want strict dependencies to fix the problem of packages occasionally being installed with incorrect file/directory ownership.

If we really need to migrate basically everything to make the hard Requires / Provides work, then I think it's fine to drop the old thing.

Technically, nothing has to be converted. The only requirement for hard user/group dependencies (which are a good thing!) is that packages creating said users or groups provides them. If something has to continue using useradd/groupadd for whatever reason (but eg sharing the spec with older distro with minimal fuss), then they can just do 'Provides: user(foo) group(bar)' and chug on.

That said, I think ultimately manual user/group creation should be something that needs an exception. In a few years or so. There are a lot of packages...

I think rather than adding manual requires, packages could opt in to hard requires by just adding
%global _use_weak_usergroup_deps 0 in the spec. These can be dropped once we one day flick this switch centrally, and for the packages who opted into this, nothing will change at that point. It's also easy to grep for and drop when no longer needed.

Yeah, strictly speaking, if we enable hard deps, then we "only" need to convert packages which have payload owned by not root and call useradd/groupadd. For example, vdr-epgfixer.spec has %defattr(-,%{vdr_user},root,-), but it doesn't call useradd, but instead relies on vdr being installed, which in turn creates the user. But that is a rare exception. Some other packages have been converted to sysusers already. Big majority of packages that carry owned files just call useradd/groupadd.

dnf repoquery --qf='%{SOURCERPM}\n' --repo=rawhide --whatrecommends 'group(*)' --whatrecommends 'user(*)'|pkgname|sort -u|wc -l → 391
rg sysusers *.spec → 159
rg -l '(useradd|groupadd|getent)' *.spec|wc -l → 313

Some of those are false positives, a rough estimate is that we'd need to convert between 232 and 313 packages.

It's a good question of how to proceed. If we just rely on packagers doing conversions on their own, this will take years and years. Thinking about this some more, I think we should do scripted conversion. It'll be a a few days of work, but within reason I think.

No doubt the vast majority of packages with non-root users/groups creates their own, but for the purposes of technical documention I think the distinction between having owned files and user/group creation is important: just using non-root in %files will take care of itself, "only" packages calling useradd/groupadd need attention. There's also no requirement for the package adding users/groups to use those entities in its own %files (I think I've seen a case or two of that as well).

I agree that those are all important distinctions. But strictly speaking, to be able to enable hard deps, we only need to convert packages which meet all of the criteria: owned payload, uses groupadd/useradd. (Other packages either already are converted, or rely on a different package, or rpm won't create any deps for them.) Or in other words, there are plenty of packages which call useradd/groupadd which we don't actually need to convert to proceed with hard deps in rpm.

My point is that the package using groupadd/useradd doesn't have to have owned payload itself to require conversion (or manual provide), just that something uses that user/group for owned payload. But, such cases would be rare anyhow.

Let's put this on hold for now. Let's push the changes to rpm and then figure out how exactly we want to deal with the packages.

Removing the table and referring to the contents of the setup package instead has been discussed before:
https://pagure.io/packaging-committee/issue/1431

Could you split this off from this one (since it's "on hold") as a separate PR? :innocent:

Let's put this on hold for now. Let's push the changes to rpm and then figure out how exactly we want to deal with the packages.

Note that I wasn't arguing against this or trying to delay this in any way, apologies if it came out that way! I was just trying to pinpoint the exact requirements further.

I split out the dropping of the list to https://pagure.io/packaging-committee/pull-request/1438.

Note that I wasn't arguing against this or trying to delay this in any way, apologies if it came out that way! I was just trying to pinpoint the exact requirements further.

That's how I understood things too.

There's not much we can do when this is only supported on Fedora-42 and later. Are there plans to backport 4.20-8 (or maybe 4.21 soon) to Fedora-41?

If not, I guess give us a ping in about a six months?

Note that "not much we can do" is due to the PR deleting the old text, if you want to change it to say "Do this for Fedora-42+, but to support Fedora-41 you'll need to do this instead" then we could merge that.

All active Fedora versions support sysusers.d integration already, it's just the feature has been disabled until now to let Fedora sort out the policy and guidelines. So technically it'd be easy to enable it in older releases too, but it does seem a risky/big change to do on what is allegedly a stable release.

technically it'd be easy to enable it in older releases too, but it does seem a risky/big change to do on what is allegedly a stable release.

Yeah, I don't think we should do this. We made this a Change for F42 to provide a clear boundary. The change is causing some integration problems here and there, and we don't want to introduce such instabilities in released versions.

I reworked the text to clearly describe the option that is supported in F42+, and the compat option that describes what is compatible with older releases. There are again two commits, please see the descriptions on both, they go into more detail.

Effectively, the change is quite minor, it just drops the requirement to have a separate sysususers file and call %sysusers_create_compat.

Thank you, taking a quick look, the latest version looks good to me :thumbsup:

Thanks everybody, and @zbyszek in particular, for all the work to make this happen!