On Fri, 2015-07-10 at 08:20 -0400, Josh Boyer wrote: > On Fri, Jul 10, 2015 at 8:05 AM, Stephen Gallagher < > sgallagh@xxxxxxxxxx> wrote: > > (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) > > You didn't offer your opinion on which of the three options you think > we should go with. I would offer option 1 is the one we'd pick. It > honors the intentions of the package maintainer the best. Which > would > you choose? > Honestly, I'm torn between options 1) and 2). On the one hand, option 1 most closely matches what would happen if you installed the same set of packages on a post-installed system. On the other hand, it means that we're putting a lot of content on the install media that might be *desirable* but isn't strictly *required*. Saving space on the download isn't always a bad thing. Also, certain spins may have valid reasons to keep certain packages off for space concerns (or they are intended for certain hardware, etc.) The only thing I'll say definitely is that option 2) is not terribly useful, since the same effect can be accomplished by option 1) or 3) and just adding extra packages explicitly in the kickstart.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
