On Fri, 2015-07-10 at 22:53 -0500, Jon wrote: > > > On Fri, Jul 10, 2015 at 7:05 AM, Stephen Gallagher < > sgallagh@xxxxxxxxxx> wrote: ... > > 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) > > > > > For now I suggest we keep with strict 'Requires' only on install > media generation (if that is possible), but ask the same questions > again next cycle. > Let's be conservative here; it's a new feature. > I'd say let the ecosystem evolve a bit before asking this question > again, particularly the Anaconda tools. > The DNF tools for sure need to evolve a bit before weak dependencies > become a thing. (it all seems related) > Well, weak deps are here; they're in the packaging guidelines now, so we need to figure out how to deal with them (even if the decision is "expressly ignore them"). > > > 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. > Now is the time to agree weak deps are here, but it's not a light > switch Boolean type thing to change in the rel-eng side.We can wait a > while for package maintainers embrace the new hotness. > And.. I'd like to reward maintainers for embracing the new weak dep > stuff. (Fedora badge anyone?) I like this idea. > Anyways... it would be great to let the compose process stay the same > for now. > Well, that's why I called out the need for testing; I'm not sure that the compose process will remain the same in F23 as it was in F22 without conscious effort, because I *think* the default case will be that using dnf to gather the packages for the compose will start pulling in Recommends packages. So if we don't want that to happen, it may require an explicit choice and modification of the call to dnf. (Yes, I'm aware that a lot of our compose tasks still use yum, but I thought I remembered that most if not all of them were scheduled to migrate to dnf this cycle). > To be specific towards the end: > * Requires: yes > * Recommend: probably no (but maybe, let them be explicit in the > compose) > * Suggest: no (let them be explicitly specified in the compose if > they are of high value for that spin or variant, ignore them > otherwise) > > Seems like the package-set for a variant or spin will become more > explicit. Which is not bad, but needs to be tested! > > Besides that, I'd like to see how comps.xml handles these new > relationships. comps.xml should be completely unaware of them, I think. Comps only specifies the set of packages that have to be in a group in order to be able to install it. It is left up to the dependency solver to figure out how that is satisfied.
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
