https://src.fedoraproject.org/rpms/smartmontools/pull-request/1

I've updated smartmontools to 7.0 and included your changes. It was not possible to merge PR, so I made changes manually. Check the changes and update PR if something is missing or close it. Thanks

smartmontools-7.0-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3cb342f650

smartmontools-7.0-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4727a746a

Looks good, thanks.  One thing, you can remove this unneeded mkdir:

diff --git a/smartmontools.spec b/smartmontools.spec
index 38a3e3f..0a4f2a3 100644
--- a/smartmontools.spec
+++ b/smartmontools.spec
@@ -55,7 +55,6 @@ rm -f examplescripts/Makefile*
 chmod a-x -R examplescripts/*
 install -D -p -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/smartmontools
 install -D -p -m 755 %{SOURCE4} $RPM_BUILD_ROOT%{_sysconfdir}/%{name}/smartd_warning.d/smartdnotif
-mkdir -p $RPM_BUILD_ROOT/%{_sysconfdir}/%{name}/smartd_warning.d
 rm -rf $RPM_BUILD_ROOT/etc/{rc.d,init.d}
 rm -rf $RPM_BUILD_ROOT%{_docdir}/%{name}
 mkdir -p $RPM_BUILD_ROOT%{_sharedstatedir}/%{name}

diff --git a/smartmontools.spec b/smartmontools.spec
index 38a3e3f..0a4f2a3 100644
--- a/smartmontools.spec
+++ b/smartmontools.spec
@@ -55,7 +55,6 @@ rm -f examplescripts/Makefile*
 chmod a-x -R examplescripts/*
 install -D -p -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/smartmontools
 install -D -p -m 755 %{SOURCE4} $RPM_BUILD_ROOT%{_sysconfdir}/%{name}/smartd_warning.d/smartdnotify
-mkdir -p $RPM_BUILD_ROOT/%{_sysconfdir}/%{name}/smartd_warning.d
 rm -rf $RPM_BUILD_ROOT/etc/{rc.d,init.d}
 rm -rf $RPM_BUILD_ROOT%{_docdir}/%{name}
 mkdir -p $RPM_BUILD_ROOT%{_sharedstatedir}/%{name}

smartmontools-7.0-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4727a746a

smartmontools-7.0-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3cb342f650

breaking existing configurations by remove "/usr/libexec/smartmontools/smartdnotify" is not very smart

DEFAULT -H -m root -M exec /usr/libexec/smartmontools/smartdnotify -n standby,10,q -d sat -s (S/../.././05|L/../../2/07|O/../../3/11) -W 0,0,50 -l error -l selftest /dev/sda /dev/sdb

Another problem: .../smartd_warning.d/smartdnotify runs the following bogus mail command:

echo "$SMARTD_MESSAGE" | mail -s "$SMARTD_FAILTYPE" 'root @ALL'

(BTW: @ALL should possibly not be in SMARTD_ADDRESS when running ALL plugins. Hmm... I should fix that upstream)

To keep existing configurations intact, I would suggest:
1) Undo all previous changes done for this Bug.
2) Apply this simple patch to /usr/libexec/smartdnotify:

  if which mail >/dev/null 2>&1
  then
-   echo "$SMARTD_MESSAGE" | mail -s "$SMARTD_FAILTYPE" "$SMARTD_ADDRESS"
+   echo "$SMARTD_FULLMESSAGE" | mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS
  fi

This does not fix the topic ("Use smartd_warning plugin method ..."), but the intention behind it ("email message ... is much better").

Note that tests could be done with smartd.conf '-M test' directive or by directly running:

  SMARTD_ADDRESS=root SMARTD_MAILER=/usr/libexec/smartdnotify \
    /etc/smartmontools/smartd_warning.sh [--dryrun]

I've tried to write notifications through smartd_warning and keep some backward compatibility as possible, to see how pretty/ugly the result will get and I was not happy with the result at all.

Thus, I've went back to the method we've used before. If someone wants to use it differently, he still can, but that is admins configuration choice, not the default we will ship. That's why I will close this bug as WONTFIX.

I've made the MESSAGE->FULLMESSAGE and FAILTYPE->SUBJECT changes as Christian suggested.