On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch <vondruch@redhat.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.


Vít




Dne 10.7.2015 v 14:05 Stephen Gallagher napsal(a):
> (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.
>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVpMSzAAoJEAzgnueZF7h8epkP/0LH9wzwx5XjS41lOnG3cr5C
2O5fEOwODffCa6une0tiJDTLvXLyx9BthEKClRHImpNFEVXg9QGGYurWbqhRfeJA
Zvc1Wzuvlf2s5iNEMFw7c8S1s3FK4/ytX4hMSx5F/9RAENq/qKxKEUU6BjiP6RxF
qP7e5yaN+y6QEuogWe2j4caqD/mfP8ZhanrvHO/KAOv8a+OAp0LZXF4uuHbfxfak
0OJw2/q9oKoO8ww5CiNJdRk+vMEXnIOT9XzMdqcpV5/GzKt42wNFqusT84Shvih2
nl2PB6Wh1rPL8oUwmQsWToEpoN0Zjh7FDVqZcbn4ja7depmJ0ub0cNTl4eJ+1AJc
fc5c+pZ5qLUKokTOvk708yy5pq2HbByqBTeBHxG51YwLZd2bUlZBQbyfadfM66Z3
FzyiEEjxA+V/mm0VXoA1kuEN1+8BnW25atifnvTLcGs5doGnEivDogaCDi8GDdCt
dR/ZLPCJySNcZJPROfrlKWd6PSUfX/M3bzdaBJcIQL/klO45dYTGolxyr0R/Muf5
B/apLMsVTyLE8Qp4HpmcmjKft1rgXNAHpe3EyXD39dhrtbpmZyMYwjO029yYAi6R
tQa2ISnuQO1hMv78A5KhseKMyHv4XKgeMaXwwdpKExZh2u8otgCBZXYq/G7MiMWc
3UQOteXvXhgWXjW5y7m4
=EPjN
-----END PGP SIGNATURE-----


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

If we did that, we'd need to switch to some other means of grouping packages. 
​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 "type" of package that defines groups to provide a similar function to metapackages without requiring garbage empty tarballs.


--
真実はいつも一つ!/ Always, there's only one truth!