RE: [ITP] Sendmail 8.14.9

["Pierre A. Humblet" <Pierre.Humblet@ieee.org>]

> -----Original Message-----
> From:  Corinna Vinschen
> Sent: Tuesday, August 26, 2014 14:50
> 
> On Aug 26 09:51, Pierre A. Humblet wrote:
> > > -----Original Message-----
> > > From:  Yaakov Selkowitz
> > > Sent: Friday, August 22, 2014 17:40
> > >
> > > On 2014-08-22 13:19, D. Boland wrote:
> > > >> On Aug 22 07:43, D. Boland wrote:
> > > >>> I re-packaged Sendmail with cygport. See:
> > > >>>
> > > >>> http://cygwin.boland.nl/x86/release/sendmail/
> > > >>
> > > >> Packaging looks good in theory.
> > > >>
> > > >> Unfortunately we have a problem.
> > > >>
> > > >> On inspection of your binary package I noticed that we have
> > > >> conflicts with exim and ssmtp packages:
> > > [snip]
> >
> > Whatever we do should be transparent to users who have already
> > installed ssmtp or exim and are updating to a newer version.
> 
> I guess that's exactly the problem.  Consider somebody has installed exim or
> ssmtp and then installs sendmail accidentally or out of curiosity.  This
> immediately overwrites the symlinks and even if the user never actually uses
> sendmail, the MTA installation is broken.
> 
> I don't have a clear concept yet if and how we should use alternatives to fix
> this problem.
> 
> Anyway, to have some working example, here's how Fedora does it:
> 
> The binaries, or symlinks to the actual binaries are called:
> 
>   /usr/sbin/sendmail.sendmail
>   /usr/bin/mailq.sendmail
>   /usr/bin/newaliases.sendmail
> 
>   /usr/sbin/sendmail.exim
>   /usr/bin/mailq.exim
>   /usr/bin/newaliases.exim
> 
>   /usr/sbin/sendmail.postfix
>   /usr/bin/mailq.postfix
>   /usr/bin/newaliases.postfix
> 
>   [analog for other MTAs]
> 
> Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> 
>   /usr/sbin/sendmail -> /etc/alternatives/mta
>   /usr/bin/mailq -> /etc/alternatives/mta-mailq
>   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> 
> And in /etc/alternatives are the symlinks to the actual binaries, as configured
> by postinstall or the user:
> 
>   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
>   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
>   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> 
> In fact, there are more than these three symlinks, mainly to rmail and to the
> man pages for the aforementioned binaries.
> 
> Maybe we can shamelessly borrow this scheme?!?
> 

I am fine with the idea, except that I don’t see the need for things such as /usr/sbin/sendmail.exim
The executables can be installed in the current locations (/usr/bin for exim) and symbolic links such as /etc/alternatives/mta can point directly to the executables.
Also it looks like we don't need to use the alternatives package itself, although we reuse the /etc/alternatives directory and naming scheme

Below is what I would do in the MTA postinstall and -config files, using mailq as an example
I am assuming that /usr/bin/mailq will not be created by setup.

In the postinstall:
If /usr/bin/mailq is a symbolic link NOT already pointing to /etc/alternatives/mta-mailq {
           create a symbolic link /etc/alternative/mta-mailq pointing to /usr/bin/mailq's target
           replace the target of /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq is a file {
           rename /usr/bin/mailq to /usr/bin/mailq.somemta
          create a symbolic link /etc/alternatives/mta-mailq pointing to /usr/bin/mailq.somemta
          create a symbolic link /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq does not exist {
          create a symbolic link /usr/bin/mailq pointing to /etc/alternatives/mta-mailq
          if the MTA has been installed previously (like, old configuration or log files already exists) {
              create a symbolic link  /etc/alternatives/mta-mailq pointing to a suitable target (if any, created by setup) for the MTA being installed
          }
}
The point of the above is not to break existing installations when updating.
Unexpected cases (like /usr/bin/mailq is a directory) are handled in the MTA-config file.

In the MTA-config file executed by the user
- verify that /usr/bin/mailq is a symbolic link to /etc/alternatives/mta-mailq, fix the situation if necessary
- present a dialog to the user with the current value of the target and ask if it should be changed to the current MTA

Pierre