Hi!
I heard (read) objections to any alternatives macros usage often. But
unless I am mistaken, we do not have any user (enough) friendly way to
support similar functionality tools with just minor differences.
I thought about it recently and I think we have similar issue solved by
systemd-sysusers macros. Unless I am mistaken, they work fine even on
rpm-ostree distributions. They have some similarities with alternatives
%post scriptlets:
those scriptlets more define values for some other tools than they need
immediate reaction. Original %pre scriptlets adding users had to be
executed during install and never outside. systemd-sysusers solves it
fine by calling a common tool and data configuration file. It makes it
possible to configure all users at a time or just the user from given
config.
I think similar approach could work with alternatives. Instead of
defining the alternative name by alternatives --install command, we
could move link name, path and priority to simple configuration snippet.
Then process that definition either per-package (for classic rpm %post)
or after-install (for rpm-ostree based distributions). The result should
be the same, just time of execution may differ. It would require
modification of alternatives to read instructions also from config file,
not only from command line parameters.
It might be naive, but wouldn't such modification allow to solve
alternatives sufficiently also for ostree based installations? Is there
a reason why this would not work? Of course it would add extra config
file per package using alternatives. Unless I am mistaken, we do not
have full featured replacement for current alternatives. Other than not
having alternatives at all. I doubt dnf swap approach is more
user-friendly, especially because it cannot be done by PackageKit GUI tools.
Is there a reason, why my idea cannot work? Is there an unsolved problem
it could not solve? Have something similar been considered already?
Best Regards,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
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
