Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #231729 > unrolled thread

Debian switchable MTA mechanism

Back to article view | Back to linux.debian.user

Contents

  Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 10:00 +0100
    Re: Debian switchable MTA mechanism Georgi Naplatanov <gosho@oles.biz> - 2021-02-16 10:20 +0100
      Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 11:00 +0100
    Re: Debian switchable MTA mechanism Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-16 10:40 +0100
      Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 10:50 +0100
        Re: Debian switchable MTA mechanism <tomas@tuxteam.de> - 2021-02-16 11:20 +0100
          Conflicting alternatives (was: Debian switchable MTA mechanism) Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-16 15:20 +0100
            Re: Conflicting alternatives (was: Debian switchable MTA mechanism) Dan Ritter <dsr@randomstring.org> - 2021-02-16 17:10 +0100
              Re: Conflicting alternatives (was: Debian switchable MTA mechanism) didar <nosferatu@purlo.in> - 2021-02-16 17:30 +0100
            Re: Conflicting alternatives (was: Debian switchable MTA mechanism) <tomas@tuxteam.de> - 2021-02-16 17:30 +0100
              Re: Conflicting alternatives (was: Debian switchable MTA mechanism) Celejar <celejar@gmail.com> - 2021-02-16 18:00 +0100
              Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-16 20:50 +0100
                Re: Conflicting alternatives <tomas@tuxteam.de> - 2021-02-16 21:40 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 00:20 +0100
                    Re: Conflicting alternatives tomas@tuxteam.de - 2021-02-17 09:20 +0100
                Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 05:40 +0100
                Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-16 23:50 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 01:30 +0100
                    Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 13:50 +0100
                      Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 16:30 +0100
                        Re: Conflicting alternatives The Wanderer <wanderer@fastmail.fm> - 2021-02-17 17:00 +0100
                          Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 17:10 +0100
                            Re: Conflicting alternatives Greg Wooledge <wooledg@eeg.ccf.org> - 2021-02-17 17:30 +0100
                              Re: Conflicting alternatives Richard Hector <richard@walnut.gen.nz> - 2021-02-18 05:40 +0100
                                Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-18 14:20 +0100
                                  Re: Conflicting alternatives Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-18 14:40 +0100
                                    Re: Conflicting alternatives Richard Hector <richard@walnut.gen.nz> - 2021-02-19 05:30 +0100
                                      Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-19 15:30 +0100
                                      Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-20 02:00 +0100
                                        Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-20 14:40 +0100
                                          Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-21 02:20 +0100
                                            Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-21 17:50 +0100
                                              Re: Conflicting alternatives Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-22 10:20 +0100
                                                Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 11:20 +0100
                                                  Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-22 12:50 +0100
                                                    Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 15:00 +0100
                                                      Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-22 15:40 +0100
                                                        Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 18:10 +0100
                                                Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 11:40 +0100
                          Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 17:20 +0100
                            Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-17 17:40 +0100
                              Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 21:40 +0100
                                Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 23:50 +0100
        Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 12:40 +0100
          Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 13:30 +0100
            Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 14:40 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 14:50 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 14:50 +0100
                Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 14:50 +0100
              Re: Debian switchable MTA mechanism rhkramer@gmail.com - 2021-02-16 15:20 +0100
        Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-16 23:40 +0100
          Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
          Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
          Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 00:40 +0100
            Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 00:50 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 01:00 +0100
    Re: Debian switchable MTA mechanism Semih Ozlem <semihozlemlinuxuser@gmail.com> - 2021-02-16 15:20 +0100
      Re: Debian switchable MTA mechanism IL Ka <kazakevichilya@gmail.com> - 2021-02-16 15:30 +0100
      Re: Debian switchable MTA mechanism Darac Marjal <mailinglist@darac.org.uk> - 2021-02-16 15:30 +0100

Page 1 of 3  [1] 2 3  Next page →

#231729 — Debian switchable MTA mechanism

Hello Debian Users.

Why Debian does't have a switchable MTA mechanism
to allow install multiple MTAs at the same time?

Fedora, Centos etc. allow users to install 
multiple MTAs at the same time.
There's a "alternatives --config mta" command
to allow to choose between alternative MTA.

-- 
kevin

[toc] | [next] | [standalone]

#231731

On 2/16/21 10:37 AM, Kevin Shell wrote:
> Hello Debian Users.
> 
> Why Debian does't have a switchable MTA mechanism
> to allow install multiple MTAs at the same time?
> 
> Fedora, Centos etc. allow users to install 
> multiple MTAs at the same time.
> There's a "alternatives --config mta" command
> to allow to choose between alternative MTA.
> 

Hi Kevin.

What is the use-case for multiple MTAs, port 25 is only one.

If you want multiple MTAs then you can use some kind of virtualization
like Docker for example.

Kind regards
Georgi

[toc] | [prev] | [next] | [standalone]

#231736

On Tue, Feb 16, 2021 at 11:13:36AM +0200, Georgi Naplatanov wrote:
> Hi Kevin.
> 
> What is the use-case for multiple MTAs, port 25 is only one.
> 
I run a VPS, for study purpose to switch between MTAs not having
to remove one to get the other, I want to keep them installed at the
same time. You can stop one and run the other, there's no conflict.

> If you want multiple MTAs then you can use some kind of virtualization
> like Docker for example.
> 

-- 
kevin

[toc] | [prev] | [next] | [standalone]

#231734

[Multipart message — attachments visible in raw view] — view raw

On Ma, 16 feb 21, 16:37:20, Kevin Shell wrote:
> Hello Debian Users.
> 
> Why Debian does't have a switchable MTA mechanism
> to allow install multiple MTAs at the same time?

Why do you need this?

> Fedora, Centos etc. allow users to install multiple MTAs at the same 
> multiple MTAs at the same time.
> There's a "alternatives --config mta" command
> to allow to choose between alternative MTA.

Installing and removing/purging packages has traditionally been very 
easy in Debian, such a mechanism would have limited benefits for 
significant added complexity.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#231735

On Tue, Feb 16, 2021 at 11:29:54AM +0200, Andrei POPESCU wrote:
> On Ma, 16 feb 21, 16:37:20, Kevin Shell wrote:
> > Hello Debian Users.
> > 
> > Why Debian does't have a switchable MTA mechanism
> > to allow install multiple MTAs at the same time?
> 
> Why do you need this?
> 

For convenience when one evaluating or learning
between multiple MTAs etc.

> > Fedora, Centos etc. allow users to install multiple MTAs at the same 
> > multiple MTAs at the same time.
> > There's a "alternatives --config mta" command
> > to allow to choose between alternative MTA.
> 
> Installing and removing/purging packages has traditionally been very 
> easy in Debian, 

removing/purging one MTA & reinstalling another MTA in the above 
situation is unnecessary and inconvenient.

>such a mechanism would have limited benefits for 
> significant added complexity.
> 
Is this a difficult task?
Isn't Debian already has a /etc/alternatives/ mechanism?

-- 
kevin

[toc] | [prev] | [next] | [standalone]

#231739

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2021 at 05:48:25PM +0800, Kevin Shell wrote:
> On Tue, Feb 16, 2021 at 11:29:54AM +0200, Andrei POPESCU wrote:
> > On Ma, 16 feb 21, 16:37:20, Kevin Shell wrote:
> > > Hello Debian Users.
> > > 
> > > Why Debian does't have a switchable MTA mechanism
> > > to allow install multiple MTAs at the same time?
> > 
> > Why do you need this?
> > 
> 
> For convenience when one evaluating or learning
> between multiple MTAs etc.

This has been a curious "cultural" experience for me, right now.

As someone deeply immersed in Debian culture (I feel *well* in
there, mind you), my first reaction was also "what for?",
exactly as the other replies in this thread went.

On the other hand, why not?

It is true that it isn't "typical Debian". Debian is deeply
rooted in the tradition of the multi-user operating system:
one sysadmin (which can be a role, or a group of people, but
is tightly coordinated and acts "as one"), and many users,
to whom you want to grant as much freedom as possible, without
giving them the means to compromise the whole system.

Think university environments in the US, some time after
last century's mid-eighties.

Therefore, you'll find apretty advanced alternatives system
for client-y stuff in Debian (editor, MUA, what not) but
not for server-y stuff.

The funny thing is how this perspective can structure an
environment to the point that those whithin don't even "see"
it anymore. This was my "aha" thing, and I thank you all
(esp. Kevin, for setting the initial question).

Kevin: Technically, this wouldn't  be a difficult thing to
do. It's basically packaging, and making sure the different
MTAs don't kill each other over resources (port 25, this
kind of thing).

Actually, where it's needed, it is done: for example, the
PostgreSQL package allows parallel installations of several
server /versions/. Why? Well, in the case of a database,
the data are much more valuable than the software (sometimes
more so than the hardware). Not allowing to gently upgrade
the server version while keeping the data might lead your
users to come to your home at night and kidnap your cat...)

You could have a look at the PostgreSQL packages for some
inspiration.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#231746 — Conflicting alternatives (was: Debian switchable MTA mechanism)

> 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".

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.

Also, as someone who happens to prefer Postfix to Exim (no particular
reason: I'm just familiar with Postfix and not with Exim), I'm actually
happy that `apt install postfix` gets me rid of Exim instead of having
it linger uselessly.

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.  ]


        Stefan

[toc] | [prev] | [next] | [standalone]

#231751 — Re: Conflicting alternatives (was: Debian switchable MTA mechanism)

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.

One of those is a daemon listening on port 25.

Another is a /usr/sbin/sendmail command that accepts new mail.

There is no requirement that the sendmail command use
localhost:25 to get the mail in; it's perfectly acceptable for
it to:

1. Do all the work itself, or
2. Use a socket to hand it off to the rest of the MTA, or
3. Send it off to another machine somewhere, even if it's
   destiny is to come back to this box

among other things.

So one package has to control both the port 25 daemon and the
sendmail command.

Debian policy is that, whenever possible, a package providing a
daemon should start that daemon at install time. This is,
perhaps, one of the more controversial policies, but it is in
effect and has been for many years.

Therefore, installing an MTA will get you both a port 25 daemon
and a sendmail command, and remove any previous installed
services.

If you keep the config directories in place, you can switch
between MTAs and feel reasonably confident that when you do
that, via apt install, it will be started with the configuration
that you already set up for it last time round. The exception
are some shared files like /etc/aliases, where you should not
expect a restored MTA to restore that config as well. Hence my
suggestion of etckeeper.

If one is trying to learn different MTAs, a few days or weeks
with each is not out of the question, and the 10-45 seconds of
apt install to change between them is reasonable.

-dsr-

[toc] | [prev] | [next] | [standalone]

#231757 — Re: Conflicting alternatives (was: Debian switchable MTA mechanism)

On Tue, Feb 16, 2021 at 11:03:14AM -0500, Dan Ritter 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.
> 
> One of those is a daemon listening on port 25.
> 
> Another is a /usr/sbin/sendmail command that accepts new mail.
> 
> There is no requirement that the sendmail command use
> localhost:25 to get the mail in; it's perfectly acceptable for
> it to:
> 
> 1. Do all the work itself, or
> 2. Use a socket to hand it off to the rest of the MTA, or
> 3. Send it off to another machine somewhere, even if it's
>    destiny is to come back to this box
> 
> among other things.
> 
> So one package has to control both the port 25 daemon and the
> sendmail command.
> 
> Debian policy is that, whenever possible, a package providing a
> daemon should start that daemon at install time. This is,
> perhaps, one of the more controversial policies, but it is in
> effect and has been for many years.
> 
> Therefore, installing an MTA will get you both a port 25 daemon
> and a sendmail command, and remove any previous installed
> services.
> 
> If you keep the config directories in place, you can switch
> between MTAs and feel reasonably confident that when you do
> that, via apt install, it will be started with the configuration
> that you already set up for it last time round. The exception
> are some shared files like /etc/aliases, where you should not
> expect a restored MTA to restore that config as well. Hence my
> suggestion of etckeeper.
> 
> If one is trying to learn different MTAs, a few days or weeks
> with each is not out of the question, and the 10-45 seconds of
> apt install to change between them is reasonable.

Talking about learning multiple MTAs - using a virtualization environment +
configuration management (ansible/chef) + apt-cache-ng works excellently.

I have been using VirtualBox VMs (under Win10) with NAT network and ansible +
subversion to learn and get dma, exim, opensmtpd as well as postfix to work for
my production requirement.

My probably inconsequential contribution to this discussion.

Didar

> 
> -dsr-
> 

-- 
Them as has, gets.

[toc] | [prev] | [next] | [standalone]

#231756 — Re: Conflicting alternatives (was: Debian switchable MTA mechanism)

[Multipart message — attachments visible in raw view] — view raw

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?

This was before HP specialised on building inkjets of [CENSORED]
quality.

> 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.

Absolutely. I think the "alternatives" system isn't the right approach
to this. Rather make things co-installable and co-runnable (as PostgreSQL
does with its different versions)

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.

I don't expect a huge amount of them (server ports, common directories,
those could be even found out by package inspection).

> Also, as someone who happens to prefer Postfix to Exim (no particular
> reason: I'm just familiar with Postfix and not with Exim), I'm actually
> happy that `apt install postfix` gets me rid of Exim instead of having
> it linger uselessly.

Yep. In the normal case, this is what the overstressed admin wants :)

> 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.
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).

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#231759 — Re: Conflicting alternatives (was: Debian switchable MTA mechanism)

On Tue, 16 Feb 2021 17:22:21 +0100
<tomas@tuxteam.de> wrote:

...

> 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?
> 
> This was before HP specialised on building inkjets of [CENSORED]
> quality.

Hey, I have a Z440 (purchased cheaply on eBay). It's a very nice, high
quality machine, and it runs linux beautifully ;)

Celejar

[toc] | [prev] | [next] | [standalone]

#231762 — 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

[toc] | [prev] | [next] | [standalone]

#231765 — Re: Conflicting alternatives

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2021 at 02:40:33PM -0500, Stefan Monnier wrote:

> > Exactly. This is user-y stuff: imagine two X servers running on behalf
> > of two users [...]

> Not sure in which way this is different from running two different SMTP
> servers on two different interfaces.

Technically not much, granted. Perhaps I haven't made clear that I
perceive that distinction as somewhat artificial.

Organisationally, and from the POV of a multi-user system, every user
has an own X server at her disposal (be it running on the host itself,
be it running on separate hardware), whereas there's just one MTA
running on the server for all users.

> > 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.

Of course not. But it'll be the only way to find out which stumbling
blocks lie beyond the package-imposed "conflicts". And then, perhaps,
convince the DDs That Be.

[...]

> No, that option is exactly what I excluded between the square brackets

Ah, got that now.

> 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).

agreed. Such a system isn't the one you want to be "living on" for
a longer period.

[...]

> 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.

I'm not very much into Debian's dependency resolver; the only I
gather (from experience and from reading things, so take with a
fist of salt) is that it's less trivial than it seems.

I have the hunch that just making the packages co-installable is
the more pleasant avenue...

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#231777 — Re: Conflicting alternatives

> Of course not. But it'll be the only way to find out which stumbling
> blocks lie beyond the package-imposed "conflicts". And then, perhaps,
> convince the DDs That Be.

W.r.t multiple MTAs, I wouldn't bother to try and convince the DDs, at
least not without a solid use-case, which seems quite unlikely.

> I have the hunch that just making the packages co-installable is
> the more pleasant avenue...

It's more pragmatic, but it won't solve the longer-term recurring issues.


        Stefan

[toc] | [prev] | [next] | [standalone]

#231784 — Re: Conflicting alternatives

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2021 at 05:52:21PM -0500, Stefan Monnier wrote:

[...]

> > I have the hunch that just making the packages co-installable is
> > the more pleasant avenue...
> 
> It's more pragmatic, but it won't solve the longer-term recurring issues.

I think I was too cryptic, sorry: I meant co-installable as, e.g.
PostgreSQL does with its different versions: you have to crack the
resources nut anyway, and then, what's the "alternatives" thing for,
anyway?

Alternatives make only sense in the presence of user interaction:
I invoke "vi" and get presented with whatever-incarnation-of-vi
is currently The One. I invoke "man vi", likewise. Still, I can
invoke (explicitly) "vim", "man vim".

What I meant by co-installable: both MTAs are up and running,
each one possibly with an own listening port [1], each one with
a different /var/spool/<mta-of-the-day>/mail. Or something.
No alternatives.

Cheers

[1] Other avenues seem worth considering, i.e. some kind of
   protocol proxy which dispatches to the different MTAs
   based on first handshake steps, what not.

 - t

[toc] | [prev] | [next] | [standalone]

#231772 — Re: Conflicting alternatives

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.

[toc] | [prev] | [next] | [standalone]

#231781 — Re: Conflicting alternatives

> 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.

My use-case is when the users (e.g. yours truly) have no intention of
folding it back into the Debian project because they are well-aware that
their needs are too marginal.

> In terms of this thread, I would say that emacs is user-y® (and
> appears in /etc/alternatives a lot).

Yes, but the maintainers of the `emacs` Debian package decided some
years ago that they didn't want to keep bothering with trying to support
several packages like emacs23, emacs24, and emacs25 at the same time and
just brought it all down to a single `emacs` (well, plus the `-nox` and
`-lucid` variants, which is part of the reason for the alternatives).
I fully agree with them that it's the best choice for them and for
Debian.  It's just not the best choice for me.


        Stefan "who sometimes feels like what he really wants is to get
                a merge of Debian, Nix, and Guix"

[toc] | [prev] | [next] | [standalone]

#231774 — 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.

[toc] | [prev] | [next] | [standalone]

#231775 — 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

[toc] | [prev] | [next] | [standalone]

#231788 — Re: Conflicting alternatives

On Tue, Feb 16, 2021 at 07:19:52PM -0500, Stefan Monnier wrote:
> 
[...]
> It'd be work in the DPKG/APT code, yes.  But it would require no extra
> work from the people doing the packaging.
> 

I know little technical details about the Debian package manager,
from an end user's perspective, the package manager should give the user
the choise not to uninstall a wanted package,
if the user don't give a choise, the package manager can perform the
default action to remove the package. 
I think this method is a better default behavior for the package manager 
for some similar packages.

-- 
kevin

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web