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".