On Tuesday, April 7, 2020 11:24:28 AM EDT Adam Williamson wrote:
On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote:
> 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.
Boy, I don't know about you but I sure am looking forward to taking a
degree in math to understand why packages are or are not installed!
I think out of this whole experience, there might need to be a rule that any
weak depency added to a package in @Core should not result in pulling is a
nearly working desktop. Maybe that should also be extended to @Base?
-Steve