For some reason I didn't receive the original email from Mike. I'll
answer via Rich's email. Hopefully I won't be misinterpreting anything.
On 10/15/15 1:43 PM, Rich Freeman wrote:
On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger <vap...@gentoo.org> wrote:
items to sort out:
- should the list of packages be in catalyst or profile-stacked content
-> imo it should be entirely in the profile
++
This would be really nice to combine with mix-ins so that instead of
special cases we could just use additional profiles (without the
normal cost of additional profiles), but absent that the approach you
have below seems fine.
I assume you're talking about the list of packages in each stage. I
would like them entirely in the profile. This gives the profile
maintainer control and I need that for some of the more exotic stuff I
work on.
- should the packages list be in a new packages.default, or should we create a
new set to hold it, or should we just go with @profile ?
-> @profile has the advantage of already existing. we have to be careful so as
to make it difficult to uninstall packages that the user does not actually
want.
I would be interested in use cases for @profile OTHER than convenience
packages (sshd, screen, etc).
Again, this is a case where having more profiles would get rid of the
need to have a compromise. Just make it @profile, and be sure to have
a profile available that doesn't have any packages beyond @system.
However, if some profiles really do need to install fairly critical
packages then maybe we should also have a packages.default in addition
to @profile.
Why would we need a new packages.default or @newset? @profile should be
enough. I guess I'm not sure how packages.default would work
differently than @profile? What would it add?
- if the packages aren't in @profile, should they be seeded in @world ?
-> imo yes as we don't want all the default packages getting depcleaned as
soon as you start using the new install. if they're in @profile, then this
is a moot point (assuming depclean does not clean out @profile).
If we end up with @system+@profile+packages.default then I'd say that
packages.default gets seeded in @world. @profile becomes difficult to
uninstall. This should be the solution if some profiles really do
need to add essential packages as well as convenience packages, but
the essential packages aren't assumed dependencies.
If we end up with just @system+@profile then I'd say that packages in
@profile get seeded in @world, and thus nothing special needs to be
done to uninstall them. This should be done if there aren't essential
profile packages.
i'm happy with having them in @profile and making sure that depclean
doesn't clear @profile.
- should stage3 be @system only, or @system+@profile, or
@system+@profile+packages.default ?
-> this depends on the previous discussion a bit. today, stage3's are
@system, but imo @system+@profile is reasonable. see next question too.
Agree it depends on the previous outcome.
Answer to this and next. stage3 should be @system+@profile (again I'm
sure what packages.default would add). I see little value in a stage3
which is @system only followed by a stage4 which is @system+@profile.
- should we release stage4's instead of stage3's ?
-> if we keep stage3 as @system-only, then we'd build stage4's which would add
@profile/whatever
-> downside is that we've been training the world to download & install stage3
for almost 15 years
-> imo as long as the default @profile is kept slim, adjusting the definition of
a stage3 is OK
I'm in agreement with your last statement, let's just adjust the
definition of stage3 and keep @profile slim. Its a lot of work to fix
up our documentation to read stage4 instead of stage3 with little gain
in my opinion. And users could be confused.
If we really needed a stage with just @system, we could add some
catalyst flag that produced a stage2.5 instead of a stage3. So a
typical run could be stage1 -> stage2 -> stage3 (where stage3 means
@system+@profile) and optionally stage1 -> stage2 -> stage2.5 -> stage3.
I don't have a strong opinion on this. I don't see the need to
maintain separate stage3s in addition to the stage4s, so we're just
arguing semantics.
I think the real question I have is what would the @profile set be
used for OTHER than convenience packages? While I did mention mix-ins
as being a better long-term solution I'm not suggesting that we should
hold off on a reasonable interim solution until we work that out.
Without mix-in support we don't really want to add more profiles,
which is the other way to go with this.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
