| 1 |
On Thu, 15 Oct 2015 13:39:40 -0400 |
| 2 |
Mike Frysinger <vapier@g.o> wrote: |
| 3 |
|
| 4 |
> On 15 Oct 2015 19:01, Alexis Ballier wrote: |
| 5 |
> > On Thu, 15 Oct 2015 11:34:22 -0400 Mike Frysinger wrote: |
| 6 |
> > > - should the packages list be in a new packages.default, or |
| 7 |
> > > should we create a new set to hold it, or should we just go with |
| 8 |
> > > @profile ? -> @profile has the advantage of already existing. we |
| 9 |
> > > have to be careful so as to make it difficult to uninstall |
| 10 |
> > > packages that the user does not actually want. |
| 11 |
> > > |
| 12 |
> > > - if the packages aren't in @profile, should they be seeded in |
| 13 |
> > > @world ? -> imo yes as we don't want all the default packages |
| 14 |
> > > getting depcleaned as soon as you start using the new install. if |
| 15 |
> > > they're in @profile, then this is a moot point (assuming depclean |
| 16 |
> > > does not clean out @profile). |
| 17 |
> > |
| 18 |
> > some kind of 'world' file in profiles like the 'packages' one that |
| 19 |
> > is just used to populate world file after (or just before) stage3 |
| 20 |
> > build ? |
| 21 |
> |
| 22 |
> i suggested the name "packages.default" originally to convey the |
| 23 |
> notion that it's just the default set of packages (you'd find in a |
| 24 |
> release). keeping the "packages." prefix seemed to be better |
| 25 |
> namespace wise. |
| 26 |
|
| 27 |
makes sense |
| 28 |
|
| 29 |
> doesn't require a PMS update because only releng tools (catalyst) |
| 30 |
> would read it. set integration would have to conform to PMS. |
| 31 |
|
| 32 |
if it's just used by catalyst to pre-seed world then indeed pms |
| 33 |
doesn't have anything to do with it, but if it's meant to be some set |
| 34 |
that profiles add to 'world' set dynamically, then interoperability is |
| 35 |
probably desired |
| 36 |
|
| 37 |
|
| 38 |
> > not sure if sets provide the same flexibility: i can imagine |
| 39 |
> > iputils in that set, but also another embedded profile with |
| 40 |
> > busybox[make-symlinks], or the bsds |
| 41 |
> |
| 42 |
> i'm not sure putting USE flag qualifiers makes sense as the next time |
| 43 |
> the package updates, the USE flags will change. if profiles want to |
| 44 |
> default USE flags, the existing package.use makes more sense imo. |
| 45 |
|
| 46 |
|
| 47 |
yes, I wasn't talking about useflags at all, and classical ways are |
| 48 |
more than enough to deal with them |
| 49 |
|
| 50 |
what I was wondering is how they'd stack: we'd likely want to have a |
| 51 |
default set in profiles/base/ that covers 90+% of cases but still leave |
| 52 |
room for subprofiles to remove what they replace by something else |
| 53 |
|
| 54 |
anyway, now that I understand the 'packages.default' is the same syntax |
| 55 |
as 'packages', I think this is already handled :) |
| 56 |
|
| 57 |
Alexis. |
Archives