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
pgpS2MQ4HGIC4.pgp
Description: PGP signature