Re: Conflicting alternatives
>> I can't see any reason why it should be fundamentally hard to make
>> dpkg/apt ignore some conflict/require statements. Maybe it would take
>> a fair bit of changes to the existing code if we want to make it work
>> seamlessly (or maybe not, I don't know), but if so, it's only because
>> the code was not written with such a situation in mind.
>
> So now we have a system with a broken (IMHO) apt running two
> programs fighting non-cooperatively over the same resources
> in order to be able to flip between them and test their
> performance. It doesn't seem like a sensible evaluation.
The purpose of allowing installation of conflicting packages or allowing
installation even in the absence of some dependency is so that the DDs
don't need to care about such corner case usage patterns.
> Who's putting in the work to actually make two MTAs coexist?
The end users who decide to use the "ignore conflict" option.
And they get to keep the pieces.
> Is this productive use of their time?
It's their (or my, in some cases) choice.
Instead of using such an option, I've had to edit the .deb packages and
remove the "conflict" statements and do a few other such tweaks.
I'd been much happier taking the same risks but without having to edit
the .debs instead telling dpkg things "ignore this dependency" "ignore
that conflict", "pretend this package has that other name".
[ In my case, I've been doing that so as to keep many different
versions of Emacs installed: by and large they don't actually
conflict (in terms of overwriting the same files, for example).
Further in the past, I'd done such things to be able to install
the `gnome` package even tho I wanted to exclude one of the packages
it depended on because it conflicted with some other package that
I wanted to have installed. ]
In all those cases, I think Debian's packagers made reasonable choices
(e.g. I agree that Debian is overall better off with just `emacs`
instead of `emacsNN`), they just didn't quite match my specific needs.
It'd be work in the DPKG/APT code, yes. But it would require no extra
work from the people doing the packaging.
Stefan
Reply to: