RPM Weak Dependencies and the install media compose process

[Stephen Gallagher]

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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150710/69011692/attachment.sig>