<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <div class="moz-cite-prefix"><tt>Thanks again, David:</tt><tt><br>

      </tt><tt><br>

      </tt><tt>I appreciate your clarification!

      </tt></div>

    <blockquote type="cite"

      cite="mid:249083A7-34C0-4DAE-8587-97E84BE4A3AF@kde.org">

      <blockquote type="cite">

        <blockquote type="cite"><tt>Please note that as from KDE

            applications release 20.08, KAlarm no longer uses Akonadi

            for alarm storage.

          </tt></blockquote>

        <tt>Sounds very good!

          I'm running Manjaro: Plasma 5.20.4, KDE-Frameworks 5.76.0, QT

          5.15.2.

          and checked KAlarm 20.08.3-1: It pulls as a dependency

          kdepim-runtime 20.08.3-1.

          For safety reasons I checked kdepim-runtime 20.08.3-1: It

          pulls as a dependency akonadi, akonadi-calendar, akonadi-notes

          and some other

          stuff.

          For me this sounds I'd get Akonadi through the backdoor?

        </tt></blockquote>

      <tt>KAlarm does still use Akonadi directly or indirectly for some

        purposes including emailing, migrating its resources when

        upgrading, accessing contacts, etc, because KDE software

        libraries use Akonadi to provide these functions. So it will

        depend on some Akonadi packages, even though it no longer uses

        Akonadi for alarm storage and retrieval.</tt></blockquote>

    <tt>But this means: Whoever wants to get rid of Akonadi (for the

      database issues around this), may not use KAlarm. In my eyes, it

      makes no sense to setup a database server and Akonadi, just for an

      alarm-clock. May be an idea for a new, lightweight application?</tt><tt><br>

    </tt><tt><br>

    </tt><tt>Regards, Michael<br>

    </tt><br>

  </body>

</html>