On Fri, Jul 10, 2015 at 7:05 AM, Stephen Gallagher <sgallagh@redhat.com> 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)
Nod, thanks for that!
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.
Very interesting. I hope this capability is used to reduce the greediness of the overall package dependency graph.
However I do anticipate a bit of package drama in reducing dependency versus functionality.
The implication seems to be a middle ground, reduce the dependency graph at the risk of reduced features.
Or at least that is my feeling from a releng & base working group perspective.
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)
For now I suggest we keep with strict 'Requires' only on install media generation (if that is possible), but ask the same questions again next cycle.
Let's be conservative here; it's a new feature.
I'd say let the ecosystem evolve a bit before asking this question again, particularly the Anaconda tools.
The DNF tools for sure need to evolve a bit before weak dependencies become a thing. (it all seems related)
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.
Now is the time to agree weak deps are here, but it's not a light switch Boolean type thing to change in the rel-eng side.
We can wait a while for package maintainers embrace the new hotness.
And.. I'd like to reward maintainers for embracing the new weak dep stuff. (Fedora badge anyone?)
Anyways... it would be great to let the compose process stay the same for now.
To be specific towards the end:
* Requires: yes
* Recommend: probably no (but maybe, let them be explicit in the compose)
* Suggest: no (let them be explicitly specified in the compose if they are of high value for that spin or variant, ignore them otherwise)
Seems like the package-set for a variant or spin will become more explicit. Which is not bad, but needs to be tested!
Besides that, I'd like to see how comps.xml handles these new relationships.
Thanks!
-Jon Disnard
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
