On Tue 16 Feb 2021 at 19:19:52 (-0500), Stefan Monnier wrote: > >> 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.
But if you're seriously figuring out how to have, say, coexisting MTAs, and fold that back into the Debian project, then I would have thought that tweaking the Control fields is part of the deliverable. In terms of this thread, I would say that emacs is user-y® (and appears in /etc/alternatives a lot). Cheers, David.