atm, everything in a stage3 tarball is based on the @system set. there are some dependencies we'd like to pull out of the @system set, but still have in the stage3 tarball. to that end, the proposal is to have a new "packages.default" file akin to the "packages.build" file. it'd have the same semantics as "packages.build" in terms of profile stacking. now a stage3 tarball would be the union of the packages listed in "packages.default" and the @system set.
Yes yes yes. I've been saying that it's silly to drop some of the packages we do at the end of stage3 that 99% of people are going to need to build a functional system, like bison and flex. Both of these were in the system set.
Sounds like something we'd use as well.
(In reply to Michał Górny from comment #2) > Sounds like something we'd use as well. (for including dbus, not replacing udev by systemd ebuild)
I'm requesting clarity (mostly from spanky) about how packages.default is expected to work. If at the end of the stage3 build we add in all the atoms from packages.default, do those atoms end up in the world file? If not, they get depcleaned by users or later catalyst stages and imho that entirely defeats the purpose. But on the other hand, it seems to mortify some devs that we wouldn't be shipping an empty world file. please share your thoughts.
Reminder. Btw., systemd-9999 +kdbus is actually already able to replace dbus.
(In reply to Rick Farina from comment #4) seeding the initial @world seems fine. i don't see why anyone would get upset over the default value when it's so trivial to modify. it's really no different from existing config files.
This seems like fodder for -dev, but I'll bite. I think it is a good idea. This would allow things like openssh to be installed by default as they are today, but be removable without a lot of hoop-jumping. Then we can save @system for true system-wide deps with circular dep issues until we have a better way for handling these.
With a heavy heart... Further clarification request. Is anyone suggesting that we make a stage4 target for catalyst and then renaming it and shipping it as a stage3? Or are we talking about modifying the current catalyst stage3 target to produce a union of packages.default and @system? I for one am very against shipping a stage4 named stage3, that's confusing.
(In reply to Rick Farina (Zero_Chaos) from comment #8) That's certainly another way of looking at it. Maybe it would be better leave stage3 as-is, and start putting official "stage4" tarballs on the Gentoo mirrors.
Ping. Is anybody working on this? It blocks removal of sys-apps/less from the system set since almost 10 years.
