1 |
On 10/15/2015 12:29 PM, Ian Stakenvicius wrote: |
2 |
> On 15/10/15 03:15 PM, Zac Medico wrote: |
3 |
>> On 10/15/2015 08:34 AM, Mike Frysinger wrote: |
4 |
>>> background: everyone wants @system to be slim, but most people |
5 |
>>> want the initial stage tarball that we release and you install |
6 |
>>> Gentoo from to not be completely sparse. we've got a bug for |
7 |
>>> this topic: https://bugs.gentoo.org/393445 |
8 |
>>> |
9 |
>>> items to sort out: - should the list of packages be in catalyst |
10 |
>>> or profile-stacked content -> imo it should be entirely in the |
11 |
>>> profile |
12 |
>>> |
13 |
>>> - should the packages list be in a new packages.default, or |
14 |
>>> should we create a new set to hold it, or should we just go |
15 |
>>> with @profile ? -> @profile has the advantage of already |
16 |
>>> existing. we have to be careful so as to make it difficult to |
17 |
>>> uninstall packages that the user does not actually want. |
18 |
> |
19 |
>> In portage, the current meaning of @profile is very similar to |
20 |
>> @system, except that it implies that members specify dependencies |
21 |
>> completely (allowing for optimal parallelization) [1]. The |
22 |
>> @profile set is only enabled for profiles from repositories that |
23 |
>> have "profile-formats = profile-set" set in metadata/layout.conf. |
24 |
>> It's an extension which is not covered by PMS. |
25 |
> |
26 |
>>> - if the packages aren't in @profile, should they be seeded in |
27 |
>>> @world ? -> imo yes as we don't want all the default packages |
28 |
>>> getting depcleaned as soon as you start using the new install. |
29 |
>>> if they're in @profile, then this is a moot point (assuming |
30 |
>>> depclean does not clean out @profile). |
31 |
> |
32 |
>> In portage, @world = @profile + @selected + @system, which means |
33 |
>> that @profile is protected from depclean since it's a part of |
34 |
>> @world. |
35 |
> |
36 |
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=532224 |
37 |
> |
38 |
> |
39 |
> |
40 |
> So just to clarify.. if we start adding these packages that are |
41 |
> removed from @system into @profile, what do we gain here? They'll |
42 |
> exist in the stage3's (which is one of the goals right?), and |
43 |
> they'll be included in @world without entries in |
44 |
> /var/lib/portage/world (so end-users will have them on their |
45 |
> systems).. Seems like everything would be the same as if they were |
46 |
> in @system, except 'emerge -e @system' wouldn't rebuild them..? Do |
47 |
> we get the advantage(s) we were looking for, going this route? |
48 |
|
49 |
|
50 |
What's probably desired is to create a stage3 profile which adds |
51 |
whatever extra stuff you want to @system, and to use the stage3 profile |
52 |
for to build stage3. After the stage3 is built, catalyst could set some |
53 |
other profile if we don't want users to have the stage3 profile by default. |
54 |
-- |
55 |
Thanks, |
56 |
Zac |