https://bugzilla.redhat.com/show_bug.cgi?id=1310092 --- Comment #11 from Richard Shaw <hobbes1069@xxxxxxxxx> --- (In reply to Ralf Senderek from comment #9) > (In reply to Richard Shaw from comment #8) > > 1. Have you considered a systemd timer rather than a cron job? > > Not yet, a cron job running every minute seemed a good trade-off to me, as I > try > to get new incoming messages fast without putting too much strain on the > system. > The user should see a new message popping up in the RAM disk automatically. > I could have avoided the cron job if I burden the user with triggering the > mail polling which I don't want to do. Switching to systemd timers might be > a good idea if I wanted to increase the frequency of incoming email polling. > > Do you have a reason to suggest switching to a systemd timer that has any > advantage in this context? Nothing other than like SysV -> Systemd, systemd timers are the "latest" way to do it. I could help you develop the file if you like but we'll save that for another day. > > 3. It would be good to add a comment on why this is necessary: > > > > if ! systemctl is-active postfix > /dev/null ; then > > systemctl enable postfix > > fi > > That is something I have thought about recently. The main reason is to make > sure > that email is sent out. I've decided to require postfix for this package, > but anyone already using another MTA would not really need that and what's > worse postfix might create a conflict with the installed alternative MTA. Both sendmail and postfix provide the MTA capability (look at rpm -q --provies <package>) but that will only make sure it's installed, not enabled or started. This is an interesting one. > The best solution would be to require any MTA be it postfix or other. > > If "Requires: sendmail" would work I'd be happy enough. But I need to test > that > before I can change this aspect of my spec file. > > There's only one place in the source code where it is needed: > (line 67 in the script "sendmail") > > 67 /usr/sbin/sendmail -f "$SENDER" "$RECIPIENT" < > /usr/lib/cryptobone/cryptobone/encryptedmessage.asc > > No other dependency is required for outgoing messages. You may want to ask about this on the devel mailing list. I'm sure there will be plenty of opinions on the matter though :) > > 6. echo "Please reboot your computer as the crypto bone daemon will start only > > while booting." > > The cryptobone daemon is unusual in the sense that it needs access to secret > information that is only available for a tiny period while the system is > booting, I tried to inform the user that a re-boot is necessary after > installation. Users will find that the GUI alerts them if the cryptobone > daemon does not run, which will also be the case, if it is stopped and > restarted like ordinary daemons. Well when you submit bodhi updates it will give you the option to suggest rebooting, but of course that only works with PackageKit, not direct dnf install/updates. > So the GUI will alert the user in any case. If the message can remain in the > spec file it might be better to place it in a %posttrans script so that it > gets displayed as the last line? Doesn't make any different as far as the packaging guidelines go but probably more appropriate overall. > > 7. What is the purpose of this? Placing systemd unit files in /etc is intended > > for the end user so they can override the files in /usr/lib/systemd/system. I'm > > pretty sure mucking around with /etc/systemd/system is forbidden. > > > > if [ -f /etc/systemd/system/cryptoboned.service ] ; then > > # re-install symlinks > > systemctl disable cryptoboned > > rm -f /etc/systemd/system/cryptoboned.service 2> /dev/null > > systemctl enable cryptoboned > > fi > > Yes, because I have previously (mistakenly) installed the unit file under > /etc You can fix this in %install as well. Basically anything that needs to happen after "make install" to fix things should be done there. The script macros are only for things that need to happen during install/uninstall/update/removal, etc. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review