| 1 |
On 15 Oct 2015 19:01, Alexis Ballier wrote: |
| 2 |
> On Thu, 15 Oct 2015 11:34:22 -0400 Mike Frysinger wrote: |
| 3 |
> > - should the packages list be in a new packages.default, or should we |
| 4 |
> > create a new set to hold it, or should we just go with @profile ? |
| 5 |
> > -> @profile has the advantage of already existing. we have to be |
| 6 |
> > careful so as to make it difficult to uninstall packages that the |
| 7 |
> > user does not actually want. |
| 8 |
> > |
| 9 |
> > - if the packages aren't in @profile, should they be seeded in |
| 10 |
> > @world ? -> imo yes as we don't want all the default packages |
| 11 |
> > getting depcleaned as soon as you start using the new install. if |
| 12 |
> > they're in @profile, then this is a moot point (assuming depclean |
| 13 |
> > does not clean out @profile). |
| 14 |
> |
| 15 |
> some kind of 'world' file in profiles like the 'packages' one that is |
| 16 |
> just used to populate world file after (or just before) stage3 build ? |
| 17 |
|
| 18 |
i suggested the name "packages.default" originally to convey the notion |
| 19 |
that it's just the default set of packages (you'd find in a release). |
| 20 |
keeping the "packages." prefix seemed to be better namespace wise. |
| 21 |
|
| 22 |
doesn't require a PMS update because only releng tools (catalyst) would |
| 23 |
read it. set integration would have to conform to PMS. |
| 24 |
|
| 25 |
> not sure if sets provide the same flexibility: i can imagine iputils in |
| 26 |
> that set, but also another embedded profile with |
| 27 |
> busybox[make-symlinks], or the bsds |
| 28 |
|
| 29 |
i'm not sure putting USE flag qualifiers makes sense as the next time the |
| 30 |
package updates, the USE flags will change. if profiles want to default |
| 31 |
USE flags, the existing package.use makes more sense imo. |
| 32 |
-mike |
Archives