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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
