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