<div dir="ltr"><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large"><span style="font-family:arial,sans-serif;font-size:small">On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch </span><span dir="ltr" style="font-family:arial,sans-serif;font-size:small">&lt;<a href="mailto:vondruch@redhat.com" target="_blank">vondruch@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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA256<br>
    <br>
    Can we just drop comps entirely (or at least trim them down
    significantly)? I know that this will not happen from day to day,
    but I see the comps just as an ugly workaround for missing weak
    dependencies, which we have now.<br>
    <br>
    <br>
    Vít<br>
    <br>
    <br>
    <br>
    <br>
    Dne 10.7.2015 v 14:05 Stephen Gallagher napsal(a):<br>
    <span style="white-space:pre-wrap">&gt; (Please keep the conversation
      on the devel list; I&#39;m CCing it the rel<br>
      &gt; -eng list to make sure all the relevant people see the
      initial message)<br>
      &gt;<br>
      &gt; This past week, the Fedora Packaging Committee approved the
      use of<br>
      &gt; &quot;weak dependencies&quot; in Fedora. What this means is that RPM
      packages can<br>
      &gt; now have three levels of dependency-resolution: Requires,
      Recommends<br>
      &gt; and Suggests.<br>
      &gt;  * Requires: the requested package cannot function without
      this<br>
      &gt; additional package installed<br>
      &gt;  * Recommends: the requested package can function in some
      minimal<br>
      &gt; capacity without this additional package installed, but the
      majority of<br>
      &gt; installations will want it for full productivity. These are
      usually<br>
      &gt; core plugins for the primary package. DNF defaults to
      installing<br>
      &gt; Recommends: dependencies automatically.<br>
      &gt;  * Suggests: the requested package can easily function
      without this<br>
      &gt; additional package. This module may provide some less-common<br>
      &gt; functionality that a user might want. DNF defaults to *not*
      installing<br>
      &gt; Suggests: packages automatically.<br>
      &gt;<br>
      &gt; Traditionally, we have only supported &quot;Requires&quot; dependencies
      and thus<br>
      &gt; the creation of install media (Live and otherwise) has been
      relatively<br>
      &gt; straightforward: we create a kickstart file that is fed into
      the<br>
      &gt; compose process containing a list of packages and groups that
      we want<br>
      &gt; installed onto the target system and the compose process
      automatically<br>
      &gt; pulls in all of the dependencies. However, with the advent of
      weak<br>
      &gt; dependencies, we have new questions that need answering about
      how this<br>
      &gt; compose process should work. (We also need to investigate
      what exactly<br>
      &gt; happens with the tools we have today - some of which still
      use yum, not<br>
      &gt; DNF - when weak dependencies are added to the mix).<br>
      &gt;<br>
      &gt; From my perspective, there are three ways that we could
      choose to go:<br>
      &gt;<br>
      &gt; 1) Follow the default DNF behavior: Requires: and Recommends:
      packages<br>
      &gt; are included on the install media (and therefore also
      installed<br>
      &gt; together onto the target system)<br>
      &gt;<br>
      &gt; 2) Include *all* dependencies - Requires, Recommends and
      Suggests - on<br>
      &gt; the install media. The installer would still follow DNF
      defaults, so<br>
      &gt; the target system would get only the Requires and Recommends
      packages<br>
      &gt; unless the Suggests: packages are explicitly selected (which
      will also<br>
      &gt; require the creation of additional comps.xml changes to
      include the<br>
      &gt; Suggests packages)<br>
      &gt;<br>
      &gt; 3) Include only Requires: dependencies by default and require
      spin<br>
      &gt; -kickstarts owners to explicitly add any Recommends or
      Suggests<br>
      &gt; packages that they also want to include. Packages added
      explicitly will<br>
      &gt; be installed as described in 2) (requiring additional
      comps.xml changes<br>
      &gt; to include Suggests stuff)<br>
      &gt;<br>
      &gt;<br>
      &gt; Note that at the moment, DNF itself does not have a
      configuration<br>
      &gt; option to tweak the default install behavior, so &#39;dnf
      install&#39;<br>
      &gt; effectively treats Recommends the same way as Requires (but
      &#39;dnf<br>
      &gt; remove&#39; will treat them differently, of course). I discussed
      this with<br>
      &gt; the DNF developers this morning and they hope to have a
      configuration<br>
      &gt; option and/or command-line argument available to change this
      behavior<br>
      &gt; before Beta Freeze, so we should still be able to ship F23
      with any of<br>
      &gt; the above options.<br>
      &gt;<br>
      &gt; I think the best time to make these decisions is now, well in
      advance<br>
      &gt; of the Alpha Freeze so we have time to make adjustments as
      needed.<br>
      &gt; Thank you for reading to the end, I know the above has been a
      wall-o&#39;<br>
      &gt; -text.<br>
      &gt;<br>
      &gt;</span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG v2<br>
    <br>
    iQIcBAEBCAAGBQJVpMSzAAoJEAzgnueZF7h8epkP/0LH9wzwx5XjS41lOnG3cr5C<br>
    2O5fEOwODffCa6une0tiJDTLvXLyx9BthEKClRHImpNFEVXg9QGGYurWbqhRfeJA<br>
    Zvc1Wzuvlf2s5iNEMFw7c8S1s3FK4/ytX4hMSx5F/9RAENq/qKxKEUU6BjiP6RxF<br>
    qP7e5yaN+y6QEuogWe2j4caqD/mfP8ZhanrvHO/KAOv8a+OAp0LZXF4uuHbfxfak<br>
    0OJw2/q9oKoO8ww5CiNJdRk+vMEXnIOT9XzMdqcpV5/GzKt42wNFqusT84Shvih2<br>
    nl2PB6Wh1rPL8oUwmQsWToEpoN0Zjh7FDVqZcbn4ja7depmJ0ub0cNTl4eJ+1AJc<br>
    fc5c+pZ5qLUKokTOvk708yy5pq2HbByqBTeBHxG51YwLZd2bUlZBQbyfadfM66Z3<br>
    FzyiEEjxA+V/mm0VXoA1kuEN1+8BnW25atifnvTLcGs5doGnEivDogaCDi8GDdCt<br>
    dR/ZLPCJySNcZJPROfrlKWd6PSUfX/M3bzdaBJcIQL/klO45dYTGolxyr0R/Muf5<br>
    B/apLMsVTyLE8Qp4HpmcmjKft1rgXNAHpe3EyXD39dhrtbpmZyMYwjO029yYAi6R<br>
    tQa2ISnuQO1hMv78A5KhseKMyHv4XKgeMaXwwdpKExZh2u8otgCBZXYq/G7MiMWc<br>
    3UQOteXvXhgWXjW5y7m4<br>
    =EPjN<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </div>

<br>--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" rel="noreferrer" target="_blank">http://fedoraproject.org/code-of-conduct</a><br></blockquote></div><br><span style="font-family:&#39;times new roman&#39;,serif;font-size:large">If we did that, we&#39;d need to switch to some other means of grouping packages. <div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif;font-size:large;display:inline">​Borrowing a bit from how the Debian/Ubuntu folks do things, probably massive virtual packages/metapackages would work well for this purpose. ​Or perhaps a &quot;type&quot; of package that defines groups to provide a similar function to metapackages without requiring garbage empty tarballs.</div></span><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-eb1f3fba570d729e06e7c995a4ecb5ab--o" style="display: none;"></font></div>