I wanted to say, no support in pkg_add for suddenly conflicting
packages after an update is by design: there is no way this can't
be seen as anything but a regression.
Imagine: you install packages A and B, you go to update them, and
suddenly the new versions conflict.
The supported cases are classic cases of upstream fiddling with their
bits, like for instance the new B is a merge of the old A and B.
But anything else will require manual intervention: if the conflict is
genuine, the user will have to make a choice.
There are several cases where maintainers should be able to do something
smart:
- the conflict is accidental. Some peripheral files have the same names,
which is usually fixed by either renaming/removing the extra files.
- the conflicting files are the exact same thing in both packages...
which means there is a common small package to build containing the files
in question, and making both new packages depending on those common files
will be enough.
- one of the new packages suddenly provides the services of the other package
"on the side", in a slightly different way. That's a perfect scenario for
MULTI_PACKAGES obviously.
In the case at hand, fvwm2 vs fvwm3, there are genuine use cases for wanting
both: fvwm2 and fvwm3 are slightly tricky beasts, and I have BOTH installed
on my machines at the same time, because I run into regression once in a blue
moon.
The main files do not conflict. Versioning the manpages will work.
Note that we routinely do much much worse in order to be able to install,
say, 10 versions of autoconf at the same time.
Tl;dr: there is no tooling solution because it's not a tooling problem.
There is some genuine human thought required to give us something that's
not a crazy design.
No comments:
Post a Comment