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 3 of 3 — ← Prev page 1 2 [3]

#231797 — Re: Conflicting alternatives

On Wed 17 Feb 2021 at 10:49:35 (-0500), The Wanderer wrote:
> On 2021-02-17 at 10:25, David Wright wrote:
> > On Wed 17 Feb 2021 at 20:45:02 (+0800), Kevin Shell wrote:
> >> 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,
> > 
> > Call that 1.
> > 
> >> if the user don't give a choise, the package manager can perform the
> >> default action to remove the package. 
> > 
> > Call that 2.
> > 
> >> I think this method is a better default behavior for the package manager 
> >> for some similar packages.
> > 
> > Is that not true now?
> > 
> > $ apt-get -s install busybox-static
> 
> > The following packages will be REMOVED:          ← case 2 ----------
> >   busybox
> > The following NEW packages will be installed:
> >   busybox-static
> 
> > ~# aptitude hold busybox
> > ~# 
> > 
> > $ apt-get -s install busybox-static
> 
> > The following packages have unmet dependencies:
> >  busybox : Conflicts: busybox-static but 1:1.30.1-4 is to be installed
> >  busybox-static : Conflicts: busybox          ← case 1 ----------
> 
> I think what he's wanting is a case which would allow installing
> busybox-static, but not insist on removing busybox. (Or the equivalent
> in his actual use-case, where the files installed by the two packages
> might not actually overlap.)
> 
> Where that runs into trouble is that even if the *files* don't overlap,
> other resources which the package needs to control exclusively quite
> possibly do - the most prominent example, from the discussion at hand
> regarding MTAs, being port 25.

I entirely agree, and that's why I wrote

  Who's putting in the work to actually make two MTAs coexist?
  Is this productive use of their time?

But these discussions often head off into odd territory, which here
seems to be:

. Break apt's conflicts mechanism and that'll fix it (just for me).
  - alternatives/dummy package appear to be able to avoid the necessity.

. Extend the alternatives mechanism and that'll fix it.
  - AIUI alternatives is aimed at a different target.

. Other distributions manage this easily.
  - what mechanism are they actually using? (rather than a
    reference to a package or heap of code).

The only realistic suggestion I've read here is from tomás,
who seems to be expressing some sort of shim dispatcher.
And I await a thought-out solution from the virtualisation crowd.

Maybe enough from the "peanut gallery".

Cheers,
David.

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

#231800 — Re: Conflicting alternatives

David Wright wrote: 
> 
> The only realistic suggestion I've read here is from tom??s,
> who seems to be expressing some sort of shim dispatcher.
> And I await a thought-out solution from the virtualisation crowd.

I mean, that's easy, but it doesn't solve the stated problem.
Each VM is a notional machine, and each machine has one MTA.

It's probably great for learning about all the MTAs, but the
original requester desperately wants to install multiple MTAs
on the same machine at the same time.

-dsr-

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

#231813 — Re: Conflicting alternatives

On Wed 17 Feb 2021 at 11:33:11 (-0500), Dan Ritter wrote:
> David Wright wrote: 
> > 
> > The only realistic suggestion I've read here is from tom??s,
> > who seems to be expressing some sort of shim dispatcher.
> > And I await a thought-out solution from the virtualisation crowd.
> 
> I mean, that's easy, but it doesn't solve the stated problem.
> Each VM is a notional machine, and each machine has one MTA.

Yes, sorry; I was thinking about Stefan's comment about "running
two different SMTP servers on two different interfaces", which seems
to be +some+ sort of use case. Might they then be able to deliver
to the a common MDA?

> It's probably great for learning about all the MTAs, but the
> original requester desperately wants to install multiple MTAs
> on the same machine at the same time.

And the OP's use case? "For convenience when one evaluating or
learning between multiple MTAs etc."

As I first wrote, why not two machines, each one with a different
MTA, and then studying their interoperation.

Or as Greg just put it:
 →
↑ ↓
 ←

Cheers,
David.

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

#231815 — Re: Conflicting alternatives

On Wed, Feb 17, 2021 at 02:31:27PM -0600, David Wright wrote:
> 
> Yes, sorry; I was thinking about Stefan's comment about "running
> two different SMTP servers on two different interfaces", which seems
> to be +some+ sort of use case. Might they then be able to deliver
> to the a common MDA?
> 
> > It's probably great for learning about all the MTAs, but the
> > original requester desperately wants to install multiple MTAs
> > on the same machine at the same time.
> 
> And the OP's use case? "For convenience when one evaluating or
> learning between multiple MTAs etc."
> 

It's not specific MTA only I think.

> As I first wrote, why not two machines, each one with a different
> MTA, and then studying their interoperation.
> 
> Or as Greg just put it:
>  →
> ↑ ↓
>  ←

Ok, if we enter the loop again
let's end the discussion thread here.
Good to talk to everyone participated. :-)

-- 
kevin

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

#231740

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.

You have an unusual use-case. 

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

Don't purge them. Just install each of them in turn. Then the
command to move to the next one is

apt install MTA-NAME

which shouldn't even incur any network traffic, since you have
them all in /var/cache/apt/archives, and will not overwrite any
config files without reason.

(You should probably install etckeeper or a similar mechanism
for keeping track of config files.)

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

You may be the first person to ever ask for such a thing. That
doesn't make it difficult, it just makes it not currently a
feature.

-dsr-

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

#231741

On Tue, Feb 16, 2021 at 06:39:03AM -0500, Dan Ritter wrote:
> 
> You have an unusual use-case. 
> 
yeah, weird use case. 🤓

> > > > Fedora, Centos etc. allow users to install multiple MTAs at the same 
> > > > multiple MTAs at the same time.
> 
[...]
> Don't purge them. Just install each of them in turn. Then the
> command to move to the next one is
> 
> apt install MTA-NAME
> 
Looks like stupid to use this command to switch MTA. 🤓

I think the Debian's /etc/alternatives/ method could be applied to MTAs
or other similar packages.

For example, there's symlink /etc/alternatives/editor => /usr/bin/vim.basic,
                                                         /usr/bin/emacs
                                                         ...

Similarly the Debian packager could add
/etc/alternatives/MTA => /usr/sbin/sendmail.sendmail
                         /usr/sbin/sendmail.postfix
                         /usr/sbin/sendmail.exim
                         ...

> which shouldn't even incur any network traffic, since you have
[...]
> > Is this a difficult task?
> > Isn't Debian already has a /etc/alternatives/ mechanism?
> 
> You may be the first person to ever ask for such a thing. That
> doesn't make it difficult, it just makes it not currently a
> feature.
> 

Yeah, I need a weird setting. 😎
> 
> 

-- 
kevin

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

#231742

Kevin Shell wrote: 
> On Tue, Feb 16, 2021 at 06:39:03AM -0500, Dan Ritter wrote:
> [...]
> > Don't purge them. Just install each of them in turn. Then the
> > command to move to the next one is
> > 
> > apt install MTA-NAME
> > 
> Looks like stupid to use this command to switch MTA. 🤓

Are you calling me stupid for answering your question?

> I think the Debian's /etc/alternatives/ method could be applied to MTAs
> or other similar packages.

It could be, but it isn't. Do you want to use a method that
works and is supported, or a method that isn't currently implemented?

-dsr-

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

#231743

On Tue, Feb 16, 2021 at 08:33:50AM -0500, Dan Ritter wrote:
> Kevin Shell wrote: 
> > On Tue, Feb 16, 2021 at 06:39:03AM -0500, Dan Ritter wrote:
> > [...]
> > > Don't purge them. Just install each of them in turn. Then the
> > > command to move to the next one is
> > > 
> > > apt install MTA-NAME
> > > 
[...]
> 
> > I think the Debian's /etc/alternatives/ method could be applied to MTAs
> > or other similar packages.
> 
> It could be, but it isn't. Do you want to use a method that
> works and is supported, or a method that isn't currently implemented?
> 

Yes, I want a method that natively supported by the Apt packages manager.
> 

-- 
kevin

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

#231744

On Tue, Feb 16, 2021 at 08:33:50AM -0500, Dan Ritter wrote:
> Kevin Shell wrote: 
> > On Tue, Feb 16, 2021 at 06:39:03AM -0500, Dan Ritter wrote:
> > [...]
> > > Don't purge them. Just install each of them in turn. Then the
> > > command to move to the next one is
> > > 
> > > apt install MTA-NAME
> > > 
> > Looks like stupid to use this command to switch MTA. 🤓
> 
> Are you calling me stupid for answering your question?

No, you misunderstand me!
I mean using the install command is not suitable.

> 
> > I think the Debian's /etc/alternatives/ method could be applied to MTAs
> > or other similar packages.
> 
> It could be, but it isn't. Do you want to use a method that
> works and is supported, or a method that isn't currently implemented?
> 
> -dsr-
> 

-- 
kevin

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

#231745

Kevin Shell wrote: 
> On Tue, Feb 16, 2021 at 08:33:50AM -0500, Dan Ritter wrote:
> > Kevin Shell wrote: 
> > > On Tue, Feb 16, 2021 at 06:39:03AM -0500, Dan Ritter wrote:
> > > [...]
> > > > Don't purge them. Just install each of them in turn. Then the
> > > > command to move to the next one is
> > > > 
> > > > apt install MTA-NAME
> > > > 
> > > Looks like stupid to use this command to switch MTA. 🤓
> > 
> > Are you calling me stupid for answering your question?
> 
> No, you misunderstand me!
> I mean using the install command is not suitable.

> > 
> > It could be, but it isn't. Do you want to use a method that
> > works and is supported, or a method that isn't currently implemented?

^ still this.

-dsr-

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

#231747

On Tuesday, February 16, 2021 08:33:50 AM Dan Ritter wrote:
> Kevin Shell wrote:

> > Looks like stupid to use this command to switch MTA. 🤓
> 
> Are you calling me stupid for answering your question?

I'm glad you (dsr) "called him out"!  (I was getting ready to do so, but, I 
hope, your reply has gotten the message across (to be more careful in his 
choice of words -- avoid emotionally loaded words).)

Have a good day!

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

#231769

On Tue 16 Feb 2021 at 17:48:25 (+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:
> > > 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.

I don't see the sense in that. It would seem far more sensible to
install one MTA on one host, another on another, and try
interoperating them. After all, that's how they'll ultimately
be used.

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

I can't see that it's very inconvenient if you save your configuration
files before you change over.

> >such a mechanism would have limited benefits for 
> > significant added complexity.
> > 
> Is this a difficult task?

The "benefits" you have given seem trivial compared with the work in
making software, with the functionality of exim, sendmail etc, coexist.

> Isn't Debian already has a /etc/alternatives/ mechanism?

AIUI all the targets of /etc/alternatives are all installed at the
same time, and can be simultaneously run without conflicting with
each other. The links merely select which target is run (and
documented) by invoking a name, like "www-browser" (→ lynx for me),
"awk" (gawk) or "rename" (the Perl one). I might be running firefox,
mawk and rename.ul (by their specific name) at the same time as the
"default" versions.

Cheers,
David.

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

#231770

On Wed 17 Feb 2021 at 07:39:15 (+0800), Kevin Shell wrote:
> On Tue, Feb 16, 2021 at 04:38:06PM -0600, David Wright wrote:
> > On Tue 16 Feb 2021 at 17:48:25 (+0800), Kevin Shell wrote:
> > 
> [...]
> > > Isn't Debian already has a /etc/alternatives/ mechanism?
> > 
> > AIUI all the targets of /etc/alternatives are all installed at the
> > same time, and can be simultaneously run without conflicting with
> > each other. The links merely select which target is run (and
> > documented) by invoking a name, like "www-browser" (→ lynx for me),
> > "awk" (gawk) or "rename" (the Perl one). I might be running firefox,
> > mawk and rename.ul (by their specific name) at the same time as the
> > "default" versions.
> 
> I asked this question because on my laptop there's an alternatives system
> that can keep several programs providing the same or similar functions
> at the same time.
> Debian also has an alternatives system but doesn't allowed to install
> multiple MTAs. 
> 
> https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c
> $ dnf info alternatives
> Name         : alternatives
> Summary      : A tool to maintain symbolic links determining default commands
> URL          : https://github.com/fedora-sysv/chkconfig
> License      : GPLv2
> Description  : alternatives creates, removes, maintains and displays information about
>              : the symbolic links comprising the alternatives system. It is possible
>              : for several programs fulfilling the same or similar functions to be
>              : installed on a single system at the same time.

I hope you won't mind if I pass on finding the difference between the
above and Debian's alternatives, ie switching MTAs. I only found
https://github.com/fedora-sysv/chkconfig/commit/c3adb7f8cd06aaf274a0b2140fffe7be75a767f9

Cheers,
David.

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

#231771

On Wed 17 Feb 2021 at 07:49:57 (+0800), Kevin Shell wrote:
> On Wed, Feb 17, 2021 at 07:47:51AM +0800, Kevin Shell wrote:
> > On Wed, Feb 17, 2021 at 07:39:15AM +0800, Kevin Shell wrote:
> > > On Tue, Feb 16, 2021 at 04:38:06PM -0600, David Wright wrote:
> > > > On Tue 16 Feb 2021 at 17:48:25 (+0800), Kevin Shell wrote:
> > > > 
> > > [...]
> > > > > Isn't Debian already has a /etc/alternatives/ mechanism?
> > > > 
> > > > AIUI all the targets of /etc/alternatives are all installed at the
> > > > same time, and can be simultaneously run without conflicting with
> > > > each other. The links merely select which target is run (and
> > > > documented) by invoking a name, like "www-browser" (→ lynx for me),
> > > > "awk" (gawk) or "rename" (the Perl one). I might be running firefox,
> > > > mawk and rename.ul (by their specific name) at the same time as the
> > > > "default" versions.
> > > > 
> > > I asked this question because on my laptop there's an alternatives system
> > > that can keep several programs providing the same or similar functions
> > > at the same time.
> > > Debian also has an alternatives system but doesn't allowed to install
> > > multiple MTAs. 
> > > 
> > > https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c
> > > $ dnf info alternatives
> > > Name         : alternatives
> > > Summary      : A tool to maintain symbolic links determining default commands
> > > URL          : https://github.com/fedora-sysv/chkconfig
> > > License      : GPLv2
> > > Description  : alternatives creates, removes, maintains and displays information about
> > >              : the symbolic links comprising the alternatives system. It is possible
> > >              : for several programs fulfilling the same or similar functions to be
> > >              : installed on a single system at the same time.
> > > 
> > besides BSD systems also have a similar system call mailwrapper
>                                                  called
> > http://man.openbsd.org/mailwrapper.8

AIUI (and I'm not one to be playing these tricks), it doesn't seem to
do more than using, say,

. Debian's alternatives to create a dummy package that satisfies apt's
  dependencies, and
. installing your favoured foreign replacement in, say, /opt.

Again, I'll pass on looking for documentation on switching MTAs
using mailwrapper.

Cheers,
David.

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

#231778

On Tue, Feb 16, 2021 at 04:38:06PM -0600, David Wright wrote:
> On Tue 16 Feb 2021 at 17:48:25 (+0800), Kevin Shell wrote:
> 
[...]
> > Isn't Debian already has a /etc/alternatives/ mechanism?
> 
> AIUI all the targets of /etc/alternatives are all installed at the
> same time, and can be simultaneously run without conflicting with
> each other. The links merely select which target is run (and
> documented) by invoking a name, like "www-browser" (→ lynx for me),
> "awk" (gawk) or "rename" (the Perl one). I might be running firefox,
> mawk and rename.ul (by their specific name) at the same time as the
> "default" versions.
> 

I asked this question because on my laptop there's an alternatives system
that can keep several programs providing the same or similar functions
at the same time.
Debian also has an alternatives system but doesn't allowed to install
multiple MTAs. 

https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c
$ dnf info alternatives
Name         : alternatives
Summary      : A tool to maintain symbolic links determining default commands
URL          : https://github.com/fedora-sysv/chkconfig
License      : GPLv2
Description  : alternatives creates, removes, maintains and displays information about
             : the symbolic links comprising the alternatives system. It is possible
             : for several programs fulfilling the same or similar functions to be
             : installed on a single system at the same time.


-- 
kevin

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

#231779

On Wed, Feb 17, 2021 at 07:39:15AM +0800, Kevin Shell wrote:
> On Tue, Feb 16, 2021 at 04:38:06PM -0600, David Wright wrote:
> > On Tue 16 Feb 2021 at 17:48:25 (+0800), Kevin Shell wrote:
> > 
> [...]
> > > Isn't Debian already has a /etc/alternatives/ mechanism?
> > 
> > AIUI all the targets of /etc/alternatives are all installed at the
> > same time, and can be simultaneously run without conflicting with
> > each other. The links merely select which target is run (and
> > documented) by invoking a name, like "www-browser" (→ lynx for me),
> > "awk" (gawk) or "rename" (the Perl one). I might be running firefox,
> > mawk and rename.ul (by their specific name) at the same time as the
> > "default" versions.
> > 
> 
> I asked this question because on my laptop there's an alternatives system
> that can keep several programs providing the same or similar functions
> at the same time.
> Debian also has an alternatives system but doesn't allowed to install
> multiple MTAs. 
> 
> https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c
> $ dnf info alternatives
> Name         : alternatives
> Summary      : A tool to maintain symbolic links determining default commands
> URL          : https://github.com/fedora-sysv/chkconfig
> License      : GPLv2
> Description  : alternatives creates, removes, maintains and displays information about
>              : the symbolic links comprising the alternatives system. It is possible
>              : for several programs fulfilling the same or similar functions to be
>              : installed on a single system at the same time.
> 
> 
> 
besides BSD systems also have a similar system call mailwrapper
http://man.openbsd.org/mailwrapper.8

-- 
kevin

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

#231780

On Wed, Feb 17, 2021 at 07:47:51AM +0800, Kevin Shell wrote:
> On Wed, Feb 17, 2021 at 07:39:15AM +0800, Kevin Shell wrote:
> > On Tue, Feb 16, 2021 at 04:38:06PM -0600, David Wright wrote:
> > > On Tue 16 Feb 2021 at 17:48:25 (+0800), Kevin Shell wrote:
> > > 
> > [...]
> > > > Isn't Debian already has a /etc/alternatives/ mechanism?
> > > 
> > > AIUI all the targets of /etc/alternatives are all installed at the
> > > same time, and can be simultaneously run without conflicting with
> > > each other. The links merely select which target is run (and
> > > documented) by invoking a name, like "www-browser" (→ lynx for me),
> > > "awk" (gawk) or "rename" (the Perl one). I might be running firefox,
> > > mawk and rename.ul (by their specific name) at the same time as the
> > > "default" versions.
> > > 
> > 
> > I asked this question because on my laptop there's an alternatives system
> > that can keep several programs providing the same or similar functions
> > at the same time.
> > Debian also has an alternatives system but doesn't allowed to install
> > multiple MTAs. 
> > 
> > https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c
> > $ dnf info alternatives
> > Name         : alternatives
> > Summary      : A tool to maintain symbolic links determining default commands
> > URL          : https://github.com/fedora-sysv/chkconfig
> > License      : GPLv2
> > Description  : alternatives creates, removes, maintains and displays information about
> >              : the symbolic links comprising the alternatives system. It is possible
> >              : for several programs fulfilling the same or similar functions to be
> >              : installed on a single system at the same time.
> > 
> > 
> > 
> besides BSD systems also have a similar system call mailwrapper
                                                 called
> http://man.openbsd.org/mailwrapper.8
> 

-- 
kevin

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

#231748

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

Just out of curiosity what is MTA short for?

Kevin Shell <kshell@gmx.com>, 16 Şub 2021 Sal, 11:57 tarihinde şunu yazdı:

> 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] | [prev] | [next] | [standalone]

#231749

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

>Just out of curiosity what is MTA short for?

Mail Transfer Agent.

This is a server that must be able to:
* get email message from MUA (mail user agent)
* forward/route it to the destination (or to the right direction at least)
* As last step, MTA sends message to the MDA (mail delivery agent) that
puts message directly into the user's mailbox

https://ittrainingday.files.wordpress.com/2013/01/c3ff4-tutorial44.jpg

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

#231750

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

On 16/02/2021 14:19, Semih Ozlem wrote:

> Just out of curiosity what is MTA short for?

Mail Transfer Agent.

Email has a whole bunch of similar acronyms to describe the various
parts of the flow of email. You compose in an MUA (Mail User Agent),
which hands it so an MSA (Mail Submission Agent - usually quite similar
to an MTA, but configured to accept messages from trusted clients),
which passes it on to the MTA (Mail Transfer Agent - SMTP is built
around the idea of passing a message from hand-to-hand to someone
nearer. A message may pass through several MTAs as it travels, and each
one may hold onto it for an arbitrary duration for scanning, batch
delivery and so on). When the mail arrives at its destination the MTA
passes the message to an MDA (Mail Delivery Agent, which has the job of
filing the message into some sort of storage). Finally, the end users
MUA will pick up the message from the storage.


>
> Kevin Shell <kshell@gmx.com <mailto:kshell@gmx.com>>, 16 Şub 2021 Sal,
> 11:57 tarihinde şunu yazdı:
>
>     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] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web