Proposal: Drop comps

Neal Gompa ngompa13 at gmail.com
Tue Jul 14 09:49:59 UTC 2015


On Tue, Jul 14, 2015 at 4:13 AM, Vít Ondruch <vondruch at 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 at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150714/e7651b85/attachment.html>


More information about the devel mailing list