On Mon, Nov 7, 2016 at 9:42 AM, Chris Adams <linux@xxxxxxxxxxx> wrote: > Once upon a time, Honza Silhan <jsilhan@xxxxxxxxxx> said: >> On Mon, Nov 7, 2016 at 3:54 AM, Chris Adams <linux@xxxxxxxxxxx> wrote: >> > I was trying to figure out why I had kernel-debug* packages installed, >> > and tracked it to xl2tpd wanting "kmod(l2tp_ppp.ko)". That is provided >> > by kernel-debug-modules-extra and kernel-modules-extra; dnf choose to >> > install the -debug version (which then pulls in the debug kernel as >> > well). >> > >> > I looked in bugzilla, and there are already two bugs (at least) for >> > this: >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1192189 >> > https://bugzilla.redhat.com/show_bug.cgi?id=1284228 >> > >> > The first one is almost 2 years old! That means that anybody that wants >> > L2TP support (which is in some default package sets I believe) gets >> > unneeded debug kernels. Surely something can be done to fix this? >> > >> > It seems that the root of the problem is that dnf resolves dependencies >> > differently from yum and refuses to change to the old well-known >> > behavior. >> >> Hi, >> The root issue is that these two packages provides the same feature >> and no other preference is specified. I've reassigned it to xl2tpd to >> give DNF hint which package should be preferred. > > Why is this xl2tpd's problem to solve? They need a module, the point of > kmod() dependencies is to specify "I need this". What's the point of > kmod() deps if the package has to still specify another package by name? > > I would think this needs to be solved on the provider side (i.e. the > kernel package), or on the dnf side (to follow the well-known yum > behavior). > This is definitely the dependency resolver's problem to solve. The problem can be broken down into two sub-issues: * Select the correct kernel "flavor" for dependencies matching the flavor running currently, so that the expressed transaction matches what the user wants. * After matching the correct flavor, install for the matching kernel version, rather than the latest one. If it is unavailable, then match to the latest available and install the kernel pieces related to it or block the install (the behavior on unavailable should probably be switchable, with the default being to block if kernel downgrade is proposed and require user intervention, but allow on upgrade automatically). Most likely this would wind up being a DNF plugin that alters the solver behavior. Alternatively, it could be something implemented as a solver behavior option for libsolv or hawkey/libdnf. It probably makes sense for it to be a libsolv behavior, though, as the problem is fairly generic and broadly useful to fix. It also makes it easy to propagate up to higher level layers like hawkey/libdnf, PackageKit, DNF, rpm-ostree, Zypper, etc. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
