On Mon, Jan 16, 2023 at 7:34 PM Petr Menšík <pemensik@xxxxxxxxxx> wrote: > > 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 In the great blueprint of image-based system[1], system should boot with an empty /etc filesystem. But I found Fedora still has two requirements on the /etc filesystem. The first one is /etc/alternatives. So I also hope we can change to another mechanism that satisfies the need for image-based system. The other is the need for /etc/ld.so.*. [1] https://0pointer.net/blog/fitting-everything-together.html -robin > _______________________________________________ > 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
