On 8/31/2012 4:48 AM, Rich Freeman wrote:
On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgo...@gentoo.org> wrote:
So please introduce virtual/compiler, virtual/linker,
virtual/posix-system, virtual/sratatata and add them to DEPEND of every
single ebuild.
Every ebuild doesn't need all of those - that is the whole point. As
Duncan already pointed out, reducing @system is a goal, but it doesn't
mean that we need to get there overnight. However, we'll never get
there if we keep going backwards.
My 2c on this:
I'm reluctant to make "sweeping statements" like this, for any number of
reasons, but -- well, I'm gonna.
IMO, getting there by slow evolution is not the right way. At some
point, @system becomes so primitive that bootstrapping must come to
depend on more than @system, or we have to add add more "phases" to the
bootstrap process, or split @system up into smaller sets or something.
The point is, we can't gradually reach a goal that's incompatible with
the fundamental premise. It's all well and good to say "let's not put
more stuff into @system because we want it to shrink," but, as it
stands, there's a de-facto policy that @system includes everything
needed to have a reasonably functional Gentoo, including all of the
compilers, development tools and interpreters portage, gcc, and your rc
system of choice rely on. Until that fundamentally changes, IMO what
belongs in @system is whatever best suits its current purpose.
For the record, I'm not saying we need to put pkgconfig in - I'm totally
agnostic about that, as I am about whether it should be brought in as a
dependency.
I just mean, probably the best way to fix the fat-@system problem is to
create some kind of vision for a more-modular "Gentoo of the Future"
first, and create a roadmap for getting there, second.
Its possible, perhaps even likely, that if we try to go the incremental
route towards @system reduction, we will find, along the way, creative
solutions to the various issues that have kept it fat-ish so far. But
that's likely to lead to a fairly ad-hoc patchwork of hacks, which imo
would most likely be inferior to what could be achieved with some kind
of destination in mind (even if that destination is subject to major
revision as Gentoo progress toward it).
-gmt
