1 |
Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted: |
2 |
|
3 |
> Right now having decent KDE and Gnome support with all the bells and |
4 |
> whistles[...] isn't that hard, [It] will likely get harder, which means |
5 |
> in practice what we'll probably have is a reasonable compromise which |
6 |
> will never be quite as polished in any one direction as it could be, |
7 |
> unless the end user does the polishing. |
8 |
|
9 |
Well stated. |
10 |
|
11 |
> RE you concerns about OpenRC being in @system. Personally I'm a fan of |
12 |
> getting rid of @system entirely except as something used to build |
13 |
> install CDs or having some sets for convenience in building systems. It |
14 |
> only exists for a few reasons that I can think of: |
15 |
> 1. Devs don't want to have ebuilds that capture dependencies on every |
16 |
> little thing. A few well-chosen virtuals like "shell utilities" or |
17 |
> whatever might help with this. |
18 |
> 2. Things like Prefix rely on the system not installing local copies of |
19 |
> libraries in the core system it needs to link to. Careful use of |
20 |
> package.provided in profiles might address this. |
21 |
> 3. We'd need many more virtuals to handle situations like FreeBSD where |
22 |
> people don't what GNU on their systems. Right now if they are system |
23 |
> packages they just define system appropriately and ebuilds don't |
24 |
> directly pull in the GNU stuff anyway. |
25 |
|
26 |
AFAIK, @system also helps resolve a few nasty circular dependencies. In |
27 |
fact, I believe that's it's primary purpose. As such I'm not sure it's |
28 |
practical (as opposed to possible, cost/benefit simply makes it |
29 |
impractical) to entirely get rid of, but it does occur to me that sets |
30 |
would be an interesting way to go. Define a few sets that together |
31 |
compose @system as we have it today, and basically package.provide them |
32 |
during the bootstrap phase. |
33 |
|
34 |
AFAIK the original stage tarball also contains a minimal installed tree, |
35 |
for similar reasons. I'm not actually sure how they interact. That'd be |
36 |
releng/arch/catalyst territory. |
37 |
|
38 |
-- |
39 |
Duncan - List replies preferred. No HTML msgs. |
40 |
"Every nonfree program has a lord, a master -- |
41 |
and if you use the program, he is your master." Richard Stallman |