Odd. This is an upgrade? Or a new install of the package?

I'll try and duplicate this on my f21 test instance here. I did test it extensively in rawhide and it did enable for me on install or upgrade. ;(

Upgrade from F20 to F21 via YUM

Apr 30 09:00:19 Updated: spamassassin-3.4.1-1.fc21.x86_64
May 05 11:52:54 Updated: spamassassin-3.4.1-2.fc21.x86_64

06-Mai-2015 00:37:12: SpamAssassin: Update processed successfully
06-Mai-2015 14:57:34: SpamAssassin: Update processed successfully
07-Mai-2015 00:43:04: SpamAssassin: No update available
08-Mai-2015 01:12:48: SpamAssassin: Update processed successfully
09-Mai-2015 01:55:32: SpamAssassin: Update processed successfully
10-Mai-2015 01:07:03: SpamAssassin: Update processed successfully
11-Mai-2015 00:25:29: SpamAssassin: Update processed successfully

%post calls:
systemctl preset sa-update.timer

But the default preset is disabled. So both the timer and the service are disabled by default.

I'd propose two changes:
1. Add to spamassassin.service:

[Install]
Also=sa-update.timer

This way 'systemctl enable spamassassin' or 'systemctl preset spamassassin' will also enable the other unit.

If this change is made sa-update.timer should be removed from %post, because it is now managed through the other unit.

It should stay in %preun/%postun because it should be stopped on uninstallation.

2. Coalesce the calls to %systemd_* macros to use only one macro per script, with both units as arguments. Right now systemd is reloaded twice which is wasteful.

Oh, I didn't see that spamassassin.service has Wants=sa-update.timer. If the timer is only supposed to run when spamassassin is active, then please disregard my point 1. above.

So yeah, the timer should run if spamassassin.service is started. But in this situation it doesn't seem to make much sense to make it enableable by itself.
Both [Install] WantedBy=spamassassin.service and the call to systemctl preset in %post should be removed.

My point 2. still stands though.

And another thing: if sa-update.timer should only run when spamassassin.service is active, PartOf=spamassassin.service should be added to the .timer unit.

well, then the problem was that this change on dist-upgrade did not enable the timer because /etc/systemd/system/spamassassin.service was enabled over months which is a legit operation and part of a typical system configuration to customize things

so if somebody replaces existing cronjobs with systemd-timers this needs to be considered - besides that the systemd-timers are a complete behavior change and not trigger emails like cronjobs and following the comments in this bugreport they obviously make over years perfect working things complexer as needed

frankly the sa-update makes sense without any service running, you can run spamassassin on demand without any enabled service at all and would not get rule updates in that case

the old cronjob was just perfect, relieable and had a configureable mail behavior

> should only run when spamassassin.service is active

no IT SHOULD NOT - look at the snippet from update-cron below, sa-updates are relevant for a ton of services and configurations just because spamassassin is a FRAMEWORK with dozens of usecases


        if [ -n "$DEBUG" -o -n "$NOTIFY_UPD" ]; then
            echo "$now: SpamAssassin: Update processed successfully"
        else
            echo "$now: SpamAssassin: Update processed successfully" >>/var/log/sa-update.log
        fi
         systemctl condrestart spamassassin.service >& /dev/null
         [ -f /usr/lib/systemd/system/amavisd.service ] && systemctl condrestart amavisd.service >& /dev/null
         systemctl --quiet is-active mimedefang.service; [ $? -eq 0 ] && systemctl reload mimedefang.service >& /dev/null
         [ -f /usr/lib/systemd/system/spampd.service ] && systemctl condrestart spampd.service >& /dev/null
        exit $status

(In reply to Harald Reindl from comment #7)
> > should only run when spamassassin.service is active
> 
> no IT SHOULD NOT - look at the snippet from update-cron below, sa-updates
> are relevant for a ton of services and configurations just because
> spamassassin is a FRAMEWORK with dozens of usecases
OK, thanks for clearing that up. In the light of this, there's still an issue with the unit files:
sa-update.timer has [Install] WantedBy=spamassassin.service. This is strictly redundant, because spamassassin.service has [Unit] Wants=sa-update.timer. So enabling or disabling sa-update.timer has no effect. 
*If* sa-update.timer should be enableable on its own, [Install] should be changed to have WantedBy=timers.target. This way enabling sa-update.timer will cause it to be started independently of whether spamassassin.service is enabled or running.

The original thing you described in the bug report is still valid: sa-update.timer is not enabled after package installation. I presume that don't have spamassassin.service enabled. Then there's nothing which would cause sa-update.timer to be enabled by default. So we're back to FPC #1441.

ok. FESCo/FPC are done with that stuff and presets are now in fedora-release. 

So, I am moving this bug to fedora-release to add a preset for sa-update.timer. 

Once thats in, which changes do we still need to make in spamassassin?

Submitted pull request upstream: 

https://pagure.io/fedora-release/pull-request/3

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.