This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] Sendmail 8.14.9


On Aug 27 11:16, Pierre A. Humblet wrote:
> > From:  Corinna Vinschen
> > 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.

That's ok, I guess.

> 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

The question is this:  IIUC, the above is almost exactly what the
alternatives mechanism is for.  Why reinvent the wheel if a proved
mechanism exists?  It also seems a bit unlean to reuse the directory
exclusively used by the alternatives package for non-alternatives stuff.

If Yaakov is available later today I will talk this through with him and
try to come up with a simple alternatives usage inside of ssmtp.  In
the case of ssmtp it's only a single sendmail symlink, but as a role
model it's hopefully sufficient.

That still doesn't mean we *must* use alternatives, but since it's
put to good use by Linux distros (and in Cygwin, too!), I'd like to
give it a fair chance :)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp1X2w338_QV.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]