| 1 |
On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger <vapier@g.o> wrote: |
| 2 |
> |
| 3 |
> items to sort out: |
| 4 |
> - should the list of packages be in catalyst or profile-stacked content |
| 5 |
> -> imo it should be entirely in the profile |
| 6 |
|
| 7 |
++ |
| 8 |
|
| 9 |
This would be really nice to combine with mix-ins so that instead of |
| 10 |
special cases we could just use additional profiles (without the |
| 11 |
normal cost of additional profiles), but absent that the approach you |
| 12 |
have below seems fine. |
| 13 |
|
| 14 |
> |
| 15 |
> - should the packages list be in a new packages.default, or should we create a |
| 16 |
> new set to hold it, or should we just go with @profile ? |
| 17 |
> -> @profile has the advantage of already existing. we have to be careful so as |
| 18 |
> to make it difficult to uninstall packages that the user does not actually |
| 19 |
> want. |
| 20 |
|
| 21 |
I would be interested in use cases for @profile OTHER than convenience |
| 22 |
packages (sshd, screen, etc). |
| 23 |
|
| 24 |
Again, this is a case where having more profiles would get rid of the |
| 25 |
need to have a compromise. Just make it @profile, and be sure to have |
| 26 |
a profile available that doesn't have any packages beyond @system. |
| 27 |
|
| 28 |
However, if some profiles really do need to install fairly critical |
| 29 |
packages then maybe we should also have a packages.default in addition |
| 30 |
to @profile. |
| 31 |
|
| 32 |
> |
| 33 |
> - if the packages aren't in @profile, should they be seeded in @world ? |
| 34 |
> -> imo yes as we don't want all the default packages getting depcleaned as |
| 35 |
> soon as you start using the new install. if they're in @profile, then this |
| 36 |
> is a moot point (assuming depclean does not clean out @profile). |
| 37 |
|
| 38 |
If we end up with @system+@profile+packages.default then I'd say that |
| 39 |
packages.default gets seeded in @world. @profile becomes difficult to |
| 40 |
uninstall. This should be the solution if some profiles really do |
| 41 |
need to add essential packages as well as convenience packages, but |
| 42 |
the essential packages aren't assumed dependencies. |
| 43 |
|
| 44 |
If we end up with just @system+@profile then I'd say that packages in |
| 45 |
@profile get seeded in @world, and thus nothing special needs to be |
| 46 |
done to uninstall them. This should be done if there aren't essential |
| 47 |
profile packages. |
| 48 |
|
| 49 |
> |
| 50 |
> - should stage3 be @system only, or @system+@profile, or |
| 51 |
> @system+@profile+packages.default ? |
| 52 |
> -> this depends on the previous discussion a bit. today, stage3's are |
| 53 |
> @system, but imo @system+@profile is reasonable. see next question too. |
| 54 |
|
| 55 |
Agree it depends on the previous outcome. |
| 56 |
|
| 57 |
> |
| 58 |
> - should we release stage4's instead of stage3's ? |
| 59 |
> -> if we keep stage3 as @system-only, then we'd build stage4's which would add |
| 60 |
> @profile/whatever |
| 61 |
> -> downside is that we've been training the world to download & install stage3 |
| 62 |
> for almost 15 years |
| 63 |
> -> imo as long as the default @profile is kept slim, adjusting the definition of |
| 64 |
> a stage3 is OK |
| 65 |
|
| 66 |
I don't have a strong opinion on this. I don't see the need to |
| 67 |
maintain separate stage3s in addition to the stage4s, so we're just |
| 68 |
arguing semantics. |
| 69 |
|
| 70 |
I think the real question I have is what would the @profile set be |
| 71 |
used for OTHER than convenience packages? While I did mention mix-ins |
| 72 |
as being a better long-term solution I'm not suggesting that we should |
| 73 |
hold off on a reasonable interim solution until we work that out. |
| 74 |
Without mix-in support we don't really want to add more profiles, |
| 75 |
which is the other way to go with this. |
| 76 |
|
| 77 |
-- |
| 78 |
Rich |
Archives