On 1/20/22 15:15, Vít Ondruch wrote:
Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):
On 1/20/22 12:52, Vít Ondruch wrote:
I have naive question why these files are not static and in /usr.
I mean, I am pretty sure I won't run `authselect select --force` or
anything similar any time soon. So why the configuration is not
static, generated at build time, not having anything in /etc unless
somebody really wants to change something.
The files are not static at all, they are change with different kinds
of authselect calls:
- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
As I said, the above is not my case and I'd say not case for most of
Fedora users.
- apply changes when package is updated: authselect apply-changes
Why is this needed? In which packages? Why simply not apply the changes
regardless of the previous state?
- apply changes when you modify your custom profile: authselect
apply-changes
This is again belongs to the initial group.
They remembers how the current configuration looks like so we can
check if user modified nsswitch and PAM configuration on their own or
not.
"user modified nsswitch and PAM configuration" is not thing I do. The
only time I needed to touch nsswitch configuration was always because
the configuration was screwed up by some updates, not by me.
IOW, from users perspective, the configuration is static. If
installation/updates changes the configuration, then it is again static
from user perspective. So I still don't see the need to have the
configuration files around by default.
Also, I think this proposal is focusing on wrong aspect, i.e. moving
files around from one location to another. It would be much better to
remove their need.
Vít
That would be the ideal world, wouldn't it? Especially for me, as
authselect maintainer :-)
Fedora 36 will move most of the users to authselect and packages won't
screw the configuration anymore. However, most of the guides on the
internet on the subject matter don't mention authselect yet so there
will be cases when users modify the configuration manually without
disabling authselect even though not intentionally. And again - not
overwriting user's configuration is important design decision to authselect.
We can of course simplify the detection and not rely on the
configuration content anymore but perhaps just rely on the presence and
validity of /etc/authselect/authselect.conf - if it is there, assume
that user wants to use authselect. I'd would certainly welcome such change.
This however would be a major functional change, so perhaps something to
consider for the next release.
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
