On Thu, 15 Oct 2015 13:39:40 -0400 Mike Frysinger <vap...@gentoo.org> wrote:
> 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. makes sense > doesn't require a PMS update because only releng tools (catalyst) > would read it. set integration would have to conform to PMS. if it's just used by catalyst to pre-seed world then indeed pms doesn't have anything to do with it, but if it's meant to be some set that profiles add to 'world' set dynamically, then interoperability is probably desired > > 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. yes, I wasn't talking about useflags at all, and classical ways are more than enough to deal with them what I was wondering is how they'd stack: we'd likely want to have a default set in profiles/base/ that covers 90+% of cases but still leave room for subprofiles to remove what they replace by something else anyway, now that I understand the 'packages.default' is the same syntax as 'packages', I think this is already handled :) Alexis.
