Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Wed, Aug 15, 2012 at 2:21 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>
> Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:
>
> > Right now having decent KDE and Gnome support with all the bells and
> > whistles[...] isn't that hard, [It] will likely get harder, which means
> > in practice what we'll probably have is a reasonable compromise which
> > will never be quite as polished in any one direction as it could be,
> > unless the end user does the polishing.
>
> Well stated.
>
> > RE you concerns about OpenRC being in @system.  Personally I'm a fan of
> > getting rid of @system entirely except as something used to build
> > install CDs or having some sets for convenience in building systems. It
> > only exists for a few reasons that I can think of:
> > 1.  Devs don't want to have ebuilds that capture dependencies on every
> > little thing.  A few well-chosen virtuals like "shell utilities" or
> > whatever might help with this.
> > 2.  Things like Prefix rely on the system not installing local copies of
> > libraries in the core system it needs to link to.  Careful use of
> > package.provided in profiles might address this.
> > 3.  We'd need many more virtuals to handle situations like FreeBSD where
> > people don't what GNU on their systems.  Right now if they are system
> > packages they just define system appropriately and ebuilds don't
> > directly pull in the GNU stuff anyway.
>
> AFAIK, @system also helps resolve a few nasty circular dependencies.  In
> fact, I believe that's it's primary purpose.  As such I'm not sure it's
> practical (as opposed to possible, cost/benefit simply makes it
> impractical) to entirely get rid of, but it does occur to me that sets
> would be an interesting way to go.  Define a few sets that together
> compose @system as we have it today, and basically package.provide them
> during the bootstrap phase.
>
> AFAIK the original stage tarball also contains a minimal installed tree,
> for similar reasons.  I'm not actually sure how they interact.  That'd be
> releng/arch/catalyst territory.

Just piping up here, as this relates to an idea that's been
percolating through my mind for a couple weeks.

I've occasionally noticed portage tell me about circular dependencies,
where the most straight forward resolution is to emerge some package
in the loop twice. The first time, with a USE flag disabled (avahi and
gtk are the usual suspects), and the second time with the USE flag
enabled.

In circumstances where it's necessary to do something like that to
reach a final desired system state, I'm not sure I see any problem
with portage automatically doing the two-stage emerge.

It also sounds like something like that could be a benefit to shrinking @system.

As far as things such as libc, where many, many packages require their
use, I don't personally see a problem with recommending that ebuilds
depend on them. My only other notable experience for Linux
distributions is Debian/Ubuntu, and a quick glance shows 16,389
packages expressing explicit dependencies on libc6 in Ubuntu 12.04.

--
:wq