On Fri, 2015-07-10 at 13:06 -0500, Dennis Gilmore wrote: > On Friday, July 10, 2015 08:05:24 AM Stephen Gallagher wrote: > > (Please keep the conversation on the devel list; I'm CCing it the > > rel > > -eng list to make sure all the relevant people see the initial > > message) > > > > This past week, the Fedora Packaging Committee approved the use of > > "weak dependencies" in Fedora. What this means is that RPM packages > > can > > now have three levels of dependency-resolution: Requires, > > Recommends > > and Suggests. > > * Requires: the requested package cannot function without this > > additional package installed > > * Recommends: the requested package can function in some minimal > > capacity without this additional package installed, but the > > majority of > > installations will want it for full productivity. These are usually > > core plugins for the primary package. DNF defaults to installing > > Recommends: dependencies automatically. > > * Suggests: the requested package can easily function without this > > additional package. This module may provide some less-common > > functionality that a user might want. DNF defaults to *not* > > installing > > Suggests: packages automatically. > > > > Traditionally, we have only supported "Requires" dependencies and > > thus > > the creation of install media (Live and otherwise) has been > > relatively > > straightforward: we create a kickstart file that is fed into the > > compose process containing a list of packages and groups that we > > want > > installed onto the target system and the compose process > > automatically > > pulls in all of the dependencies. However, with the advent of weak > > dependencies, we have new questions that need answering about how > > this > > compose process should work. (We also need to investigate what > > exactly > > happens with the tools we have today - some of which still use yum, > > not > > DNF - when weak dependencies are added to the mix). > > > > From my perspective, there are three ways that we could choose to > > go: > > > > 1) Follow the default DNF behavior: Requires: and Recommends: > > packages > > are included on the install media (and therefore also installed > > together onto the target system) > > > > 2) Include *all* dependencies - Requires, Recommends and Suggests - > > on > > the install media. The installer would still follow DNF defaults, > > so > > the target system would get only the Requires and Recommends > > packages > > unless the Suggests: packages are explicitly selected (which will > > also > > require the creation of additional comps.xml changes to include the > > Suggests packages) > > > > 3) Include only Requires: dependencies by default and require spin > > -kickstarts owners to explicitly add any Recommends or Suggests > > packages that they also want to include. Packages added explicitly > > will > > be installed as described in 2) (requiring additional comps.xml > > changes > > to include Suggests stuff) > > > > > > Note that at the moment, DNF itself does not have a configuration > > option to tweak the default install behavior, so 'dnf install' > > effectively treats Recommends the same way as Requires (but 'dnf > > remove' will treat them differently, of course). I discussed this > > with > > the DNF developers this morning and they hope to have a > > configuration > > option and/or command-line argument available to change this > > behavior > > before Beta Freeze, so we should still be able to ship F23 with any > > of > > the above options. > > > > I think the best time to make these decisions is now, well in > > advance > > of the Alpha Freeze so we have time to make adjustments as needed. > > Thank you for reading to the end, I know the above has been a wall > > -o' > > -text. > > I think without some flag in dnf that anaconda can toggle on the > users request > we should only include Requires and Recommends on the media if users > have a > toggle to say also include Suggested packages then and only then > should we > include Suggests. the experience for installs from Media should > match > installs from the network. As we have shown time and time again > manually > managed lists do not scale or work well. so i think defining suggests > in comps > groups will be prone to a lot of issues. > I think 1) makes the most sense as long as we have the following test cases that pass: Assuming a package named "engine" which Recommends: "common-plugin" and Suggests: "uncommon-plugin": * A kickstart that includes "engine" will result in an install medium that includes "common-plugin" and does not include "uncommon-plugin" * Installing from this medium (and no network) with an environment group that includes "engine" will install both "engine" and "common -plugin" and will not encounter an error by not being able to locate "uncommon-plugin". * A kickstart that includes "engine" but also includes "-uncommon -plugin" (explicitly excluding it from the medium) will result in a medium that includes only "engine". * Any environment group that includes "engine" will appear in Anaconda (as long as that group does not require "common-plugin" as a mandatory package). * Installing from this medium (and no network) with an environment group that includes "engine" will install "engine" and will not encounter an error by not being able to locate "common-plugin" or "uncommon-plugin".
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct