Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Rich Freeman]

On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <floppym@g.o> wrote:
> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>> Thus, not adding it to @system in no way means it's not considered
>> mandatory for a normal install, it just means the ultimate goal is to
>> have all the deps specified and nothing left in @system, and while
>> progress isn't fast by a long shot, the first thing is to ensure we're
>> not regressing!
>>
>
> If the ultimate goal is to eliminate @system entirely (which it
> probably isn't), we will need to revisit the way stage building works.
> If understand correctly, a stage3 contains @system and its
> dependencies.

The goal would be to eliminate @system entirely.

The solution to stage3 would be to have a set like @system of default
starting packages.  It might even be a defined set that users could
make use of (emerge @default), but ebuilds could not assume that they
are present.

To build them you just start with a working Gentoo system and emerge them.

>
> The smallest you can really make @system under that circumstance would
> be a working toolchain and the utilities necessary to build any other
> needed packages. I think that is the goal that most people have been
> shooting for lately.

Nobody is suggesting that a system containing no packages whatsoever
should be bootable, let alone usable to bootstrap everything else.
There would be some minimal set of packages needed to bootstrap the
rest.  However, ebuilds would need to explicitly declare their need
for them rather than assuming they are present.  Virtuals could be
used to simplify this.

In fact, there is a simple way to transition to such a system.  Start
by defining a virtual that contains everything that is in @system
(setting aside the issue that this is profile-dependent), and adding
that as a DEPEND and RDEPEND to every ebuild.  Then start paring it
down per-ebuild.

The goal is not to have working Gentoo systems that contain nothing on
their hard drives, but rather to eliminate the arbitrary collection of
packages that must be present everywhere, because some software that
might or might not even be installed could need them.

Rich