On 10/15/2015 02:51 PM, Anthony G. Basile wrote: > On 10/15/15 5:20 PM, Zac Medico wrote: >> On 10/15/2015 02:13 PM, Mike Frysinger wrote: >> >> so if iputils is in @profile, and i do: >> emerge -C iputils >> i don't get the ugly warning about it being in @system, but if i do: >> emerge @world >> iputils comes back. i think that's OK actually since people can do: >> emerge @selected >> which has the classic @world meaning. >> -mike >> >> People need to be able to use @world without it pulling in unwanted >> packages, since it's the only way to properly do a full update of all >> relevant packages (relevant packages being those that would not be >> removed by depclean). > But that's true of @system packages now. If a user does `emerge -C > iputils` they get a warning about it being in the system set and when > they do `emerge @world` it comes back.
I think it's obvious that such packages don't belong in @system, unless we're talking about a profile where iputils is absolutely required for some reason. > The only change in moving it to @profile is the warning. What's the point of getting rid of the warning if the package is going to get pulled back in on the next @world update? Either way, the end result it that the user has to go through some hoops (/etc/portage/profile overrides) if they don't want that package installed again. > Also, I think the other change is during the > building of the /tmp/stage1root during stage1, @system won't include > iputils and this saves on the number of packages built. The last time I checked, @system was not used for stage1. Catalyst used package.build instead. Has that changed? -- Thanks, Zac
