On 10/15/2015 12:29 PM, Ian Stakenvicius wrote: > On 15/10/15 03:15 PM, Zac Medico wrote: >> On 10/15/2015 08:34 AM, Mike Frysinger wrote: >>> background: everyone wants @system to be slim, but most people >>> want the initial stage tarball that we release and you install >>> Gentoo from to not be completely sparse. we've got a bug for >>> this topic: https://bugs.gentoo.org/393445 >>> >>> items to sort out: - should the list of packages be in catalyst >>> or profile-stacked content -> imo it should be entirely in the >>> profile >>> >>> - 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. > >> In portage, the current meaning of @profile is very similar to >> @system, except that it implies that members specify dependencies >> completely (allowing for optimal parallelization) [1]. The >> @profile set is only enabled for profiles from repositories that >> have "profile-formats = profile-set" set in metadata/layout.conf. >> It's an extension which is not covered by PMS. > >>> - 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). > >> In portage, @world = @profile + @selected + @system, which means >> that @profile is protected from depclean since it's a part of >> @world. > >> [1] https://bugs.gentoo.org/show_bug.cgi?id=532224 > > > > So just to clarify.. if we start adding these packages that are > removed from @system into @profile, what do we gain here? They'll > exist in the stage3's (which is one of the goals right?), and > they'll be included in @world without entries in > /var/lib/portage/world (so end-users will have them on their > systems).. Seems like everything would be the same as if they were > in @system, except 'emerge -e @system' wouldn't rebuild them..? Do > we get the advantage(s) we were looking for, going this route?
What's probably desired is to create a stage3 profile which adds whatever extra stuff you want to @system, and to use the stage3 profile for to build stage3. After the stage3 is built, catalyst could set some other profile if we don't want users to have the stage3 profile by default. -- Thanks, Zac
