----- Original Message ----- > From: "Stephen Gallagher" <sgallagh@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Cc: rel-eng@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, July 10, 2015 2:05:24 PM > Subject: RPM Weak Dependencies and the install media compose process > > (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). Let me just clarify that there is still one little difference. A package cannot be installed if one of its *required* packages is not available while an unavailable *recommended* package does not block the installation. > 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. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
