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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
