Do we have alternatives to alternatives?

[Petr Menšík]

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

[Miro Hrončok]

On 16. 01. 23 12:34, Petr Menšík 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 recall that Sphinx in Fedora once used https://modules.readthedocs.io to 
switch between Python 2 and Python 3.

https://src.fedoraproject.org/rpms/python-sphinx/c/ad8724f17a9ca2881833f17ba...

One of the great benefit of this was that the users could change the meaning of 
the commands on their command line, but the actual commands in /usr/bni 
remained stable.

Another good thing about this was that there were no nasty scriptlets that 
would hunt us for generations (IIRC we needed to add scriptlets in c9s Python 
just because we used to use alternatives in RHEL 8 -- to allow upgrades).

[Vít Ondruch]

Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):
> 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 have not tried this:

https://github.com/openSUSE/libalternatives

But I like the idea.

Vít

[Neal Gompa]

On Mon, Jan 16, 2023 at 11:56 AM Vít Ondruch  wrote:
> Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):
> > 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 have not tried this:
>
> https://github.com/openSUSE/libalternatives
>
> But I like the idea.

I packaged it a while ago: https://copr.fedorainfracloud.org/coprs/ngompa/alts/

I didn't bring it into Fedora yet, though.

[Robin Lee]

On Mon, Jan 16, 2023 at 7:34 PM Petr Menšík  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue