Provides: MTA and smtpdaemon?

Manuel Wolfshant wolfy at nobugconsulting.ro
Tue Apr 10 20:05:58 UTC 2007


On 04/10/2007 10:23 PM, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
>   
>> esmtp, for example. It provides all the mta alternatives entry, but not
>> all the functionalities. However smtpdaemon is better for a mta that 
>> provides all the functionalities behind the mta alternatives (that is 
>> send mail, receive mail on the smtp port and deliver mail locally).
>>     
>
> AFAIK, the smtpdaemon virtual provide predates mta by a good margin;
> it was done to not have a file dep on /usr/sbin/sendmail to be provided
> by exim/postfix/sendmail, because at the time RPM didn't handle:
>
> Provides /path/to/file
>
> correctly.
>
> Bill
>
>   
So now we have 3 resources which all work, since rpm did learn to 
provide files correctly:
- smtpdaemon
- MTA
- /usr/sbin/sendmail


Can we attach specific meaning to each one (and/or drop whatever is not 
needed) and use this a guide ? I suggest
-  smtpdaemon for programs which can really be used as daemons (axigen / 
exim / postfix / qmail / sendmail / xmail) (not that all of them are 
packaged or available now; even if they are not, we could kindly ask the 
respective packagers to follow our guidelines)
- MTA for anything that can be used as (or claims to be) a MTA (even 
send-only) (all the above plus esmtp and ssmtp)
I admit I prefer MTA as a virtual resource name rather than 
/usr/sbin/sendmail because (to meat at least) it looks much more 
descriptive. However, given that lots of applications depend on 
/usr/sbin/sendmail, it will certainly be needed to be kept for "a while".


Bugs should then be filed against applications (rhel inclusive !) 
depending on what they really need (MTA for mailx and mdadm for 
instance. Once these programs are fixed (will they ?) the MTA programs 
should fix the provided resources, too.

Comments ? Improvements ?


    Manuel (still looking for a clean solution to keep ssmtp as a 
replacement for sendmail on centos 3/4 & FC 6 without using a private 
repo or using rpm --force / --nodeps)




More information about the fedora-devel-list mailing list