On 15 Oct 2015 19:01, Alexis Ballier wrote: > On Thu, 15 Oct 2015 11:34:22 -0400 Mike Frysinger wrote: > > - 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. > > > > - 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). > > some kind of 'world' file in profiles like the 'packages' one that is > just used to populate world file after (or just before) stage3 build ?
i suggested the name "packages.default" originally to convey the notion that it's just the default set of packages (you'd find in a release). keeping the "packages." prefix seemed to be better namespace wise. doesn't require a PMS update because only releng tools (catalyst) would read it. set integration would have to conform to PMS. > not sure if sets provide the same flexibility: i can imagine iputils in > that set, but also another embedded profile with > busybox[make-symlinks], or the bsds i'm not sure putting USE flag qualifiers makes sense as the next time the package updates, the USE flags will change. if profiles want to default USE flags, the existing package.use makes more sense imo. -mike
signature.asc
Description: Digital signature
