I have added some code to pkg_config and put it as pkg_postinst so the config file is being configured by portage.
I paste here the pkg_postinst section because I don't know why, but I can't attach a file: pkg_postinst() { local conffile="/etc/ssmtp/ssmtp.conf" local hostname=`hostname -f` local domainname=`hostname -d` mv ${conffile} ${conffile}.orig sed -e "s:rewriteDomain=:rewriteDomain=${domainname}:g" \ -e "s:_HOSTNAME_:${hostname}:" \ -e "s:^mailhub=mail:mailhub=mail.${domainname}:g" \ ${conffile}.orig > ${conffile}.pre if [ `use ssl` ]; then sed -e "s:^#UseTLS=YES:UseTLS=YES:g" \ ${conffile}.pre > ${conffile} mv ${conffile}.pre ${conffile}.orig else mv ${conffile}.pre ${conffile} fi } Regards. Ferdy
Nice improvement :) I have added this code to the ebuild.
This is not a good improvement. It screws up existing ssmtp.conf because it's done in pkg_postinst() instead of src_install(). It needs to be done in the latter so that CONFIG_PROTECT is respected. For example my (previously working) ssmtp.conf now says: rewriteDomain=zk3.dec.comzk3.dec.com along with other bad things.
That's right !!!!! aaaaaaaagh ;) Ok, I'll try using src_install. If I get good results I'll post the new ebuild. sorry :( Regards, Ferdy
Also I don't think that USE=ssl is a good basis for UseTLS=YES. Many users want ssl for browsers, etc. but have mailservers that don't support TLS. I'd suggest either (1) using a new USE=tls flag or (2) leaving the setting commented by default in the ssmtp configuration, to be uncommented only by admins who know what they're doing. Either way, please don't make it dependent on USE=ssl
Thanks Ferdy :-)
Well...... people should use emerge -vp ssmtp so the can see which USEs are going to be considered... I think it should depend on SSL instead on TLS, but it's ok if you think it should depend on TLS, I'll make it depending on TLS. Regards, Ferdy
(Note I don't think there's a tls USE-flag yet...)
I know, but maybe is time to add it :) I don't know who manage USE variables, but I've noticed that there are many packages that uses lots of non-defined USE variables. I have here an ebuild working..... I make it depending on SSL or TLS. You are the devs :) so it is up to you ;) Regards, Ferdy
Personally, I'd prefer if it weren't dependent on either. I'll let raker choose what he wants to do... it's his bug. ;-)
Hehe, ok, I'll post three ebuilds so raker can choose what 'policy' he agrees :) 1) Depending on SSL 2) Depending on TLS 3) Depending on ANYTHING ;) Regards, Ferdy
Created attachment 13373 [details] (update - tls) ssmtp-2.60.3-r1.ebuild It depends on USE=ssl. (in all ebuilds the problem Aron reported is fixed)
Comment on attachment 13373 [details] (update - tls) ssmtp-2.60.3-r1.ebuild It uses USE=tls
Created attachment 13374 [details] (update - ssl) ssmtp-2.60.3-r1.ebuild It uses USE=ssl
Created attachment 13375 [details] (update - neither ssl nor tls) ssmtp-2.60.3-r1.ebuild This doesn't set up the config file. (It has all new stuff commented out)
I personally thought it was nice to have the appropriate configuration setup "out of the box"... i.e. - When net-mail/courier is installed and you run ebuild /var/db/pkg/foo/bar-1.2.3.ebuild config; imaps,pop3s, and smtps services are setup and turned on when starting the mailserver. Somebody who doesn't want the TLS functionality could easily do a USE="-ssl" while building ssmtp... I think adding a tls flag would just confuse things for users.
I have removed the auto ssl config generation code.
Nick, I really don't mind if you would rather have this dependent on USE=ssl. I didn't mean to throw a wrench in the works. The main problem was that it needs to occur in src_install instead of pkg_postinst. So long as that's solved, I'm happy.
The code is commented and back in src_install... i mulled over this issue for a couple weeks... and came to the point where I realized... only people who are more experienced and professional users will need the ssl config... so they will look deeper into the ebuild to uncomment associated code.
ssmtp-2.60.4 is currently in portage and seems to be working quite well.
