On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger <vap...@gentoo.org> wrote: > > items to sort out: > - should the list of packages be in catalyst or profile-stacked content > -> imo it should be entirely in the profile
++ This would be really nice to combine with mix-ins so that instead of special cases we could just use additional profiles (without the normal cost of additional profiles), but absent that the approach you have below seems fine. > > - should the packages list be in a new packages.default, or should we create a > new set to hold it, or should we just go with @profile ? > -> @profile has the advantage of already existing. we have to be careful so > as > to make it difficult to uninstall packages that the user does not actually > want. I would be interested in use cases for @profile OTHER than convenience packages (sshd, screen, etc). Again, this is a case where having more profiles would get rid of the need to have a compromise. Just make it @profile, and be sure to have a profile available that doesn't have any packages beyond @system. However, if some profiles really do need to install fairly critical packages then maybe we should also have a packages.default in addition to @profile. > > - if the packages aren't in @profile, should they be seeded in @world ? > -> imo yes as we don't want all the default packages getting depcleaned as > soon as you start using the new install. if they're in @profile, then this > is a moot point (assuming depclean does not clean out @profile). If we end up with @system+@profile+packages.default then I'd say that packages.default gets seeded in @world. @profile becomes difficult to uninstall. This should be the solution if some profiles really do need to add essential packages as well as convenience packages, but the essential packages aren't assumed dependencies. If we end up with just @system+@profile then I'd say that packages in @profile get seeded in @world, and thus nothing special needs to be done to uninstall them. This should be done if there aren't essential profile packages. > > - should stage3 be @system only, or @system+@profile, or > @system+@profile+packages.default ? > -> this depends on the previous discussion a bit. today, stage3's are > @system, but imo @system+@profile is reasonable. see next question too. Agree it depends on the previous outcome. > > - should we release stage4's instead of stage3's ? > -> if we keep stage3 as @system-only, then we'd build stage4's which would add > @profile/whatever > -> downside is that we've been training the world to download & install stage3 > for almost 15 years > -> imo as long as the default @profile is kept slim, adjusting the definition > of > a stage3 is OK I don't have a strong opinion on this. I don't see the need to maintain separate stage3s in addition to the stage4s, so we're just arguing semantics. I think the real question I have is what would the @profile set be used for OTHER than convenience packages? While I did mention mix-ins as being a better long-term solution I'm not suggesting that we should hold off on a reasonable interim solution until we work that out. Without mix-in support we don't really want to add more profiles, which is the other way to go with this. -- Rich
