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