#1107630 kmail should depend on kdepim-addons and not just recommend them

Package:
kmail
Source:
kmail
Description:
full featured graphical email client
Submitter:
Matthias Heinz
Date:
2025-06-16 19:21:01 UTC
Severity:
normal
#1107630#5
Date:
2025-06-10 21:25:45 UTC
From:
To:
Hi!

During a recent upgrade kmail lost the functionality for me to display/parse
meeting invites and I was just seeing them as inline text. I really thought
this was a bug in kmail, but had no time to investigate further until now.

Today I found out that I was missing kdepim-addons. Sometimes in past a
necessary library seems to have been moved there. Or maybe the package was
newly created? I'm not sure.

But imho kdepim-addons should be a dependency for kmail, not just a
recommendation, to prevent other users from my experience.

Most other users will probably not be affected, because they have the kdepim
meta package installed, unlike I had.


Best regards
Matthias

#1107630#10
Date:
2025-06-11 19:09:17 UTC
From:
To:
I’m not sure I would agree with that.  Depends are the packages required for
the core functionality of the package, which in the case of Kmail is sending
and receiving email.  Recommends are the packages necessary for the ancillary
functionality of the package, parsing meeting invites being an example.

Based on your description, my sense is that the current dependencies are
correct.  Those wanting all the ancillary functionality of Kmail should
install all the recommended packages, either by manually installing them or by
automatically installing all recommended packages.

#1107630#15
Date:
2025-06-16 18:08:54 UTC
From:
To:
Hej,

Am Mittwoch, 11. Juni 2025, 21:09:17 CEST schrieb Soren Stoutner:

I agree with Soren here.

Setting a hard dependency on an addons package feels quite wrong. I
believe that a Recommends is the best solution here. The package gets
installed by default, but can still be removed by those who do not want
it.
If you're not installing recommend packages, then you'll have to live
with the occasional missing feature.

At the same time, if we were to set kdepim-addons as a hard dependency
for kmail, then I'm sure some user would complain that they cannot
remove an optional addons package they don't want.

At this stage I see little reason to change the current behaviour.

#1107630#20
Date:
2025-06-16 18:45:49 UTC
From:
To:
Hi,

oh, I'm sorry that I did forget to post a follow up on this.

I agree with you both. I've taken a closer look at the package and discussed
this with a bit with Allen Winter from KDE and stated my opinion that it might
be a reasonable idea to get rid of this package all along and integrate the
plugins into the regarding packages. But it is their choice.

I hope nobody else runs into my initial problem until then. (Most people
probably have the whole kdepim suite installed and therefore never will).

Best regards
Matthias

Am Montag, 16. Juni 2025, 20:08:54 Mitteleuropäische Sommerzeit schrieb
Patrick Franz:

#1107630#25
Date:
2025-06-16 19:19:40 UTC
From:
To:
Patrick Franz <deltaone@debian.org> writes:

Me too.

+1

+1

The logic is:

Debian exists for user freedom.

"Recommends" installs packages that most users will use; This frees them
from needing to spend an undefined amount of time learning what package
they need to install to enable expected functionality.

"Recommends" also allows users to uninstall functionality that is
non-essential to them; this liberty exists for users who are not in the
majority "most users" category; this liberty frees users from the
potential tyranny of opinionated maintainers.  When a users see packages
in the list that they don't want, they remove them.  Users who wish to
blacklist packages should add those packages to a post-upgrade script.

"--no-install-recommends" is for users who would rather spend an
undefined amount of time learning what package to install to enable
functionality that most users expect.  This liberty is for people who
want as little as possible, even if it costs them time.  Such is the
virtue of stoics--whose liberties we also uphold.

Regards,
Nicholas