Re: Conflicting alternatives
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.
>
> tomas@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.
Reply to: