| 1 |
For some reason I didn't receive the original email from Mike. I'll |
| 2 |
answer via Rich's email. Hopefully I won't be misinterpreting anything. |
| 3 |
|
| 4 |
On 10/15/15 1:43 PM, Rich Freeman wrote: |
| 5 |
> On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger <vapier@g.o> wrote: |
| 6 |
>> items to sort out: |
| 7 |
>> - should the list of packages be in catalyst or profile-stacked content |
| 8 |
>> -> imo it should be entirely in the profile |
| 9 |
> ++ |
| 10 |
> |
| 11 |
> This would be really nice to combine with mix-ins so that instead of |
| 12 |
> special cases we could just use additional profiles (without the |
| 13 |
> normal cost of additional profiles), but absent that the approach you |
| 14 |
> have below seems fine. |
| 15 |
|
| 16 |
I assume you're talking about the list of packages in each stage. I |
| 17 |
would like them entirely in the profile. This gives the profile |
| 18 |
maintainer control and I need that for some of the more exotic stuff I |
| 19 |
work on. |
| 20 |
> |
| 21 |
>> - should the packages list be in a new packages.default, or should we create a |
| 22 |
>> new set to hold it, or should we just go with @profile ? |
| 23 |
>> -> @profile has the advantage of already existing. we have to be careful so as |
| 24 |
>> to make it difficult to uninstall packages that the user does not actually |
| 25 |
>> want. |
| 26 |
> I would be interested in use cases for @profile OTHER than convenience |
| 27 |
> packages (sshd, screen, etc). |
| 28 |
> |
| 29 |
> Again, this is a case where having more profiles would get rid of the |
| 30 |
> need to have a compromise. Just make it @profile, and be sure to have |
| 31 |
> a profile available that doesn't have any packages beyond @system. |
| 32 |
> |
| 33 |
> However, if some profiles really do need to install fairly critical |
| 34 |
> packages then maybe we should also have a packages.default in addition |
| 35 |
> to @profile. |
| 36 |
|
| 37 |
Why would we need a new packages.default or @newset? @profile should be |
| 38 |
enough. I guess I'm not sure how packages.default would work |
| 39 |
differently than @profile? What would it add? |
| 40 |
|
| 41 |
> |
| 42 |
>> - if the packages aren't in @profile, should they be seeded in @world ? |
| 43 |
>> -> imo yes as we don't want all the default packages getting depcleaned as |
| 44 |
>> soon as you start using the new install. if they're in @profile, then this |
| 45 |
>> is a moot point (assuming depclean does not clean out @profile). |
| 46 |
> If we end up with @system+@profile+packages.default then I'd say that |
| 47 |
> packages.default gets seeded in @world. @profile becomes difficult to |
| 48 |
> uninstall. This should be the solution if some profiles really do |
| 49 |
> need to add essential packages as well as convenience packages, but |
| 50 |
> the essential packages aren't assumed dependencies. |
| 51 |
> |
| 52 |
> If we end up with just @system+@profile then I'd say that packages in |
| 53 |
> @profile get seeded in @world, and thus nothing special needs to be |
| 54 |
> done to uninstall them. This should be done if there aren't essential |
| 55 |
> profile packages. |
| 56 |
|
| 57 |
i'm happy with having them in @profile and making sure that depclean |
| 58 |
doesn't clear @profile. |
| 59 |
|
| 60 |
> |
| 61 |
>> - should stage3 be @system only, or @system+@profile, or |
| 62 |
>> @system+@profile+packages.default ? |
| 63 |
>> -> this depends on the previous discussion a bit. today, stage3's are |
| 64 |
>> @system, but imo @system+@profile is reasonable. see next question too. |
| 65 |
> Agree it depends on the previous outcome. |
| 66 |
|
| 67 |
Answer to this and next. stage3 should be @system+@profile (again I'm |
| 68 |
sure what packages.default would add). I see little value in a stage3 |
| 69 |
which is @system only followed by a stage4 which is @system+@profile. |
| 70 |
> |
| 71 |
>> - should we release stage4's instead of stage3's ? |
| 72 |
>> -> if we keep stage3 as @system-only, then we'd build stage4's which would add |
| 73 |
>> @profile/whatever |
| 74 |
>> -> downside is that we've been training the world to download & install stage3 |
| 75 |
>> for almost 15 years |
| 76 |
>> -> imo as long as the default @profile is kept slim, adjusting the definition of |
| 77 |
>> a stage3 is OK |
| 78 |
|
| 79 |
I'm in agreement with your last statement, let's just adjust the |
| 80 |
definition of stage3 and keep @profile slim. Its a lot of work to fix |
| 81 |
up our documentation to read stage4 instead of stage3 with little gain |
| 82 |
in my opinion. And users could be confused. |
| 83 |
|
| 84 |
If we really needed a stage with just @system, we could add some |
| 85 |
catalyst flag that produced a stage2.5 instead of a stage3. So a |
| 86 |
typical run could be stage1 -> stage2 -> stage3 (where stage3 means |
| 87 |
@system+@profile) and optionally stage1 -> stage2 -> stage2.5 -> stage3. |
| 88 |
|
| 89 |
> I don't have a strong opinion on this. I don't see the need to |
| 90 |
> maintain separate stage3s in addition to the stage4s, so we're just |
| 91 |
> arguing semantics. |
| 92 |
> |
| 93 |
> I think the real question I have is what would the @profile set be |
| 94 |
> used for OTHER than convenience packages? While I did mention mix-ins |
| 95 |
> as being a better long-term solution I'm not suggesting that we should |
| 96 |
> hold off on a reasonable interim solution until we work that out. |
| 97 |
> Without mix-in support we don't really want to add more profiles, |
| 98 |
> which is the other way to go with this. |
| 99 |
> |
| 100 |
|
| 101 |
|
| 102 |
-- |
| 103 |
Anthony G. Basile, Ph.D. |
| 104 |
Gentoo Linux Developer [Hardened] |
| 105 |
E-Mail : blueness@g.o |
| 106 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 107 |
GnuPG ID : F52D4BBA |
Archives