I agree, for rpm integration rpm should just take over the whole thing rather
than try meddle with package scriptlets.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hm, a good question to ask maybe is if we are fine with how the alternatives
work in the context of the system as is though. Maybe a more clever approach
would be to manage alternatives entirely through rpm cli and rpmdb, without
having to deal with the existing implementations, which obviously
This is actually a nice use case to look how to make spec files more
declarative and what road blocks are ahead. The main issue here is that there
are all those moving pieces and rpm is not great in having them all in random
order. Everything needs to go to the right place in the spec and so it
I guess this would mean that it would be a transaction task to identify changes
in alternatives and process them, similar to a transaction trigger?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Alternatives seem like a natural thing to be handled by RPM, but instead, it's
handled by whatever a vendor cooks up for managing alternatives (which can get
ugly specwise fast).
For packagers, alternatives managed by RPM could simply look like a
`%alternative source dest` in the `%files`
