In addition to determining the MTA pulled in by default for packages which require mail-transport-agent in order to function (the provider of default-mta), I'd like to propose as a release goal that we not have any MTA in standard anymore. I've actually worked towards this goal for a while now, and made a fair bit of progress; this mail documents the remaining work required, most of which is simple dependency/priority changes and patch application.
Only one package in standard or above currently Depends on a mail-transport-agent: - bsd-mailx: should have the same priority as an MTA (optional). Two packages in standard or above Recommends bsd-mailx (indirectly via the mailx virtual package): - exim4-base: moved to optional as part of this goal. - logrotate; could just Suggests mailx (or use sendmail directly and Suggests an MTA). Four packages in standard or above Recommends mail-transport-agent: - cron: I've already filed bugs on cron (and anacron) with patches to support sending cronjob output to syslog, so that it will not disappear into /dev/null without an MTA installed. - at: I'd argue for this becoming priority optional, though it wouldn't be particularly hard to write a patch like the one for cron instead. - procmail: should have the same priority as an MTA (optional) - mutt: can easily Suggests a mail-transport-agent, since it supports IMAP and SMTP, leaving aside more exotic configurations like getmail/fetchmail. (That leaves aside the question of whether mutt should be standard or optional, but I think either way it should only Suggests an MTA.) With the above changes made, all providers of mail-transport-agent could become priority optional or lower, including the provider of default-mta. (To the extent this affects the selection of default-mta, I'd suggest that it might argue in favor of making default-mta one that only supports smarthosts and does not queue locally, leaving the choice of what MTA to run on a mail server up to the end user, but that question matters a lot less to me than removing MTAs from standard.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130528032733.GA30967@leaf