On 5/11/24 12:56, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 10, 2024 at 01:28:07PM +0200, Florian Festi wrote:
>> Anyone interested in picking this up? I remember quite a few people
>> being exited about this when it was announced with the rpm-4.19 Change.
>
> I would be interested in making this happen.
>
> You mentioned that the transition "requires some care". What are
> the problems?
There are Requires created for the users and groups. To make this work
the Provides need to be there first - obviously. So one will probably
need to set %_use_weak_usergroup_deps for a transition period. At least
until the first mass rebuild.
There are also a large number of packages that are using useradd:
grep useradd *.spec | cut -d: -f1 | sort -u | wc
281 281 4090
We need to think what to do with them.
The sysusers macros are much less used actually:
grep sysusers_requires_compat *.spec | cut -d: -f1 | sort -u | wc
53 53 725
grep sysusers_create_compat *.spec | cut -d: -f1 | sort -u | wc
101 101 1476
>> This whole thing probably needs to be a Global Change involving a change
>> to the Packaging Guidelines [4] and may be an Mass Package Change
>> (although that might be avoided by changing the macros in
>> systemd-rpm-macros to NOPs).
>
> The macros are written in a way that if the user/group exist,
> no operation is done. Thus, naively, I would think that if rpm
> starts to create users and groups on its own, then the existing
> scriptlets would become noops. That would mean that we could enable
> the feature in rpm without any mass package changes first.
That might work, but I have not looked deep enough into that to do that
blindly.
> If the rpm approach works, I think it'd make sense to
> a) change the macros to be noops,
> b) do a mass package change to strip the scriptlets from all packages.
> That's probably the right thing to do for the rawhide branch, but
> as usual, the question becomes how to handle packages that use a
> common branch for older releases. But the Mass Change process is
> intended to deal with such cases.
One way to deal with this is to keep the noop macros until all current
Fedora versions are using the new method.
It's probably not super complicated it just wasn't something we wanted
to do during the actual RPM update - which already was a lot of "fun"
without also enabling the new user handling.
Then there is ofc all the paper work needed.
Florian
PS: Note that the upcoming RPM 4.20 release is extending the support to
"m" lines in sysuser files (which adds users to existing groups)
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
