On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
Maybe libsecret spec could provide an empty libsecret-never-fail subpackage
that would hard-require a libsecret server and the applications like geary would
require that subpackage. (Alternatively libsecret-devel could provide a RPM
macro that the applications use to add a direct dependency on a server.) But
this abstractions is quite academic provided the only libsecret server in
Fedora is gnome-keyring.
I wouldn't focus on a particular package because the situation can
repeat with any other package in the future, and would make the question
more generic.
Is it expected, are we OK with the fact, that with default settings
of weak dependencies enabled in dnf and anaconda, installing @group
can eventually pull in way more packages than originally listed
in the group, beyond the hard dependencies? Should following the weak
dependencies be a boolean yes/no setting, or should it be a score and
should the resolver have an option to favour weak dependencies when
resolving the first level of depenencies from the original package
list but decrease (perhaps radically) favouring them in next and
next-next-levels, potentially even taking into account if the
intermediate dependencies were explicit ones or implicit libraries?
In other words, if I list packages A, B, C in transaction, I might
want to have their weak dependencies thrown onto the system as well.
But if A requires libX.so and libY.so, and package X requires G and
that has weak dependency on K, I might not care about K.
If I explicitly say I want G, then again, sure, give me K as well.
--
Jan Pazdziora
Product Owner, Platform Security Readiness, Red Hat