On Tue 16 Feb 2021 at 14:40:33 (-0500), Stefan Monnier wrote: > Dan Ritter [2021-02-16 11:03:14] wrote: > > Stefan Monnier wrote: > >> Still, there is to me no good reason not to allow installing both exim > >> and postfix at the same time. I think it's just a tradeoff between how > >> often this could be useful and how much work it takes to tweak the > >> packages. > > An MTA has to provide certain things, or else it is not an MTA. > [...] > > Dan, you're just repeating what the rest of the thread already said. > These are just parts of the tradeoff, and yes, this ends up strongly > favoring the current choice. We're in violent agreement on this. > > to...@tuxteam.de [2021-02-16 17:22:21] wrote: > > On Tue, Feb 16, 2021 at 09:17:13AM -0500, Stefan Monnier wrote: > >> > Therefore, you'll find apretty advanced alternatives system > >> > for client-y stuff in Debian (editor, MUA, what not) but > >> > not for server-y stuff. > >> Hmm... so that's your take on it? > >> Maybe you're right. I was thinking of the display manager as > >> a counter-example (you can install lxdm, gdm, and others simultaneously > >> even though you can only use one at a the same time), but you might > >> argue that it's not "server-y stuff". > > Exactly. This is user-y stuff: imagine two X servers running on behalf > > of two users (some time ago, those were a separate hardware: remember > > those shiny HP thingies with a whopping 6 MB of RAM and a huge monitor? > > Not sure in which way this is different from running two different SMTP > servers on two different interfaces. > > > The start (@Kevin: still listening?) would be to unpackage a package, > > hack the Conflicts: (& friends) fields, try to install both and watch > > the fireworks. Then fix the issues one by one. > > FWIW, I've done such surgeries occasionally (e.g. to install old Emacs > packages), but it's not fun. > > >> But I do think Debian's packaging system should be improved to > >> accommodate such needs: it should be possible and easy to override > >> conflicts so as to force-install both Postfix and Exim (for instance). > >> [ and I don't mean it just when you install the second package, but > >> also during the rest of the lifetime of the system, until you remove > >> the override. ] > > ISTR there was an apt option ("force") to override such things. > > No, that option is exactly what I excluded between the square brackets > because it only applies during the execution of the command (so you end > up with a system in a broken state and from then on dpkg/apt will just > keep complaining about it until you revert it), whereas what we need is > more like a config file listing conflicts we want to keep ignoring (I've > similarly wanted some way to list package dependencies that dpkg should > currently ignore). > > > Of course you end with a package database in a "strange" state; > > perhaps the database isn't prepared to contain a package set > > which has dependency conflicts. I don't even know what a dependency > > resolver will do in such cases. But there was at least one > > --force-depends option (which isn't mentioned in the man page > > these days). > > 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. Who's putting in the work to actually make two MTAs coexist? Is this productive use of their time? Cheers, David.