<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 10, 2015 at 7:05 AM, Stephen Gallagher <span dir="ltr">&lt;<a href="mailto:sgallagh@redhat.com" target="_blank"><span class="" id=":3ki.1" tabindex="-1">sgallagh</span>@<span class="" id=":3ki.2" tabindex="-1">redhat</span>.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Please keep the conversation on the devel list; I&#39;m CCing it the rel<br>
-eng list to make sure all the relevant people see the initial message)<br></blockquote><div><br></div><div>Nod, thanks for that!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This past week, the Fedora Packaging Committee approved the use of<br>
&quot;weak dependencies&quot; in Fedora. What this means is that RPM packages can<br>
now have three levels of dependency-resolution: Requires, Recommends<br>
and Suggests.<br>
 * Requires: the requested package cannot function without this<br>
additional package installed<br>
 * Recommends: the requested package can function in some minimal<br>
capacity without this additional package installed, but the majority of<br>
installations will want it for full productivity. These are usually<br>
core plugins for the primary package. DNF defaults to installing<br>
Recommends: dependencies automatically.<br>
 * Suggests: the requested package can easily function without this<br>
additional package. This module may provide some less-common<br>
functionality that a user might want. DNF defaults to *not* installing<br>
Suggests: packages automatically.<br>
<br></blockquote><div><br></div><div>Very interesting. I hope this capability is used to reduce the greediness of the overall package dependency graph.</div><div>However I do anticipate a bit of package drama in reducing dependency versus functionality.</div><div>The implication seems to be a middle ground, reduce the dependency graph at the risk of reduced features.</div><div>Or at least that is my feeling from a <span class="" id=":3ki.3" tabindex="-1">releng</span> &amp; base working group perspective.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Traditionally, we have only supported &quot;Requires&quot; dependencies and thus<br>
the creation of install media (Live and otherwise) has been relatively<br>
straightforward: we create a kickstart file that is fed into the<br>
compose process containing a list of packages and groups that we want<br>
installed onto the target system and the compose process automatically<br>
pulls in all of the dependencies. However, with the advent of weak<br>
dependencies, we have new questions that need answering about how this<br>
compose process should work. (We also need to investigate what exactly<br>
happens with the tools we have today - some of which still use yum, not<br>
DNF - when weak dependencies are added to the mix).<br>
<br>
>From my perspective, there are three ways that we could choose to go:<br>
<br>
1) Follow the default DNF behavior: Requires: and Recommends: packages<br>
are included on the install media (and therefore also installed<br>
together onto the target system)<br>
<br>
2) Include *all* dependencies - Requires, Recommends and Suggests - on<br>
the install media. The installer would still follow DNF defaults, so<br>
the target system would get only the Requires and Recommends packages<br>
unless the Suggests: packages are explicitly selected (which will also<br>
require the creation of additional comps.xml changes to include the<br>
Suggests packages)<br>
<br>
3) Include only Requires: dependencies by default and require spin<br>
-kickstarts owners to explicitly add any Recommends or Suggests<br>
packages that they also want to include. Packages added explicitly will<br>
be installed as described in 2) (requiring additional comps.xml changes<br>
to include Suggests stuff)<br>
<br>
<br></blockquote><div><br></div><div>For now I suggest we keep with strict &#39;Requires&#39; only on install media generation (if that is possible), but ask the same questions again next cycle.</div><div>Let&#39;s be conservative here; it&#39;s a new feature.</div><div>I&#39;d say let the ecosystem evolve a bit before asking this question again, particularly the Anaconda tools.</div><div>The <span class="" id=":3ki.4" tabindex="-1">DNF</span> tools for sure need to evolve a bit before weak dependencies become a thing. (it all seems related)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that at the moment, DNF itself does not have a configuration<br>
option to tweak the default install behavior, so &#39;dnf install&#39;<br>
effectively treats Recommends the same way as Requires (but &#39;dnf<br>
remove&#39; will treat them differently, of course). I discussed this with<br>
the DNF developers this morning and they hope to have a configuration<br>
option and/or command-line argument available to change this behavior<br>
before Beta Freeze, so we should still be able to ship F23 with any of<br>
the above options.<br>
<br>
I think the best time to make these decisions is now, well in advance<br>
of the Alpha Freeze so we have time to make adjustments as needed.<br>
Thank you for reading to the end, I know the above has been a wall-o&#39;<br>
-text.<br></blockquote><div><br></div><div>Now is the time to agree weak <span class="" id=":3ki.5" tabindex="-1">deps</span> are here, but it&#39;s not a light switch Boolean type thing to change in the rel-<span class="" id=":3ki.6" tabindex="-1">eng</span> side.</div><div>We can wait a while for package maintainers embrace the new hotness. </div><div>And.. I&#39;d like to reward maintainers for embracing the new weak <span class="" id=":3ki.7" tabindex="-1">dep</span> stuff. (Fedora badge anyone?)</div><div>Anyways... it would be great to let the compose process stay the same for now.</div><div><br></div><div>To be specific towards the end:</div><div>* Requires: yes<br></div><div>* Recommend: probably no  (but maybe, let them be explicit in the compose)</div><div>* Suggest: no  (let them be explicitly specified in the compose if they are of high value for that spin or variant, ignore them otherwise)</div><div><br></div><div>Seems like the package-set for a variant or spin will become more explicit. Which is not bad, but needs to be tested!</div><div><br></div><div>Besides that, I&#39;d like to see how comps.<span class="" id=":3ki.8" tabindex="-1">xml</span> handles these new relationships.</div><div><br></div><div>Thanks!</div><div><br></div></div>-- <br><div><br>-Jon <span class="" id=":3ki.9" tabindex="-1">Disnard</span></div>
</div></div>