<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large"><span style="font-family:arial,sans-serif;font-size:small">On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher </span><span dir="ltr" style="font-family:arial,sans-serif;font-size:small">&lt;<a href="mailto:sgallagh@redhat.com" target="_blank">sgallagh@redhat.com</a>&gt;</span><span style="font-family:arial,sans-serif;font-size:small"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large">​I think this option makes the most sense, as it captures the current behavior of DNF into the composition process. I honestly do not believe it would make sense to allow the default behavior to differ from DNF, especially as the vast majority of composes now are live images, making it basically impossible to customize pre-install.​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large">​While I appreciate the idea for completeness, I do not think this would go over well as we update our packages to actually utilize weak dependencies efficiently. However, I would be in favor of a kickstart parameter that could switch on and off the inclusion of recommended and suggested packages in a compose.</div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large">For example, in the %packages section, &quot;--no_recommended_packages&quot; and &quot;--add_suggested_packages&quot; switches could be handy to alter the default behavior to whatever a composer would want.<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large;display:inline">This is absolutely foolhardy, as we are fully deviating from ​how DNF behaves and enshrining the hacks with comps that we simply do not need anymore.</div></div><div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large">​Excellent!​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large">​I completely agree, as the earlier we can decide on these things, the better we&#39;ll all be. Thank you for bringing it up!</div></div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">真実はいつも一つ!/ Always, there&#39;s only one truth!<br></div></div>
</div><font face="yw-402608bc37fe50adb11a5899295781aeb83d248d-2f0344170d7e3c4536f52cbf45c7ac42--o" style="display: none;"></font></div>