| 1 |
On Wed, Aug 15, 2012 at 8:01 AM, Fabian Groffen <grobian@g.o> wrote: |
| 2 |
> On 15-08-2012 07:50:42 -0400, Rich Freeman wrote: |
| 3 |
>> On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@g.o> wrote: |
| 4 |
>> > There are only a few packages I've seen that depend on a certain |
| 5 |
>> > (min/max) version of glibc, and when in use for Prefix, mostly use |
| 6 |
>> > "!prefix? ( elibc_glibc? ( ...) )" |
| 7 |
>> > stuff at the moment. |
| 8 |
>> |
| 9 |
>> Half the packages in portage link to libc, though they don't actually |
| 10 |
>> declare this dependency due to the policy of not declaring policies in |
| 11 |
>> @system. If you got rid of @system then they'd need to declare them. |
| 12 |
> |
| 13 |
> Yeah, so just don't do that. |
| 14 |
|
| 15 |
In that case then just ignore that whole section of my post. :) |
| 16 |
Personally I consider the existence of @system a bit of a hack - like |
| 17 |
the big kernel lock. It works OK, but here and there we run into |
| 18 |
issues with it. |
| 19 |
|
| 20 |
Williamh pointed out that the plan for now is to virtualize |
| 21 |
openrc/systemd, which certainly is a solution to that problem. Being |
| 22 |
an evolutionary vs revolutionary solution it is probably the better |
| 23 |
next step. In fact, if you kept making many steps like that one |
| 24 |
before long @system would become mostly a big collection of virtuals |
| 25 |
anyway, and at that point its only reason for being would be as an |
| 26 |
arbitrary list of packages that ebuild maintainers shouldn't add as |
| 27 |
dependencies, at which point you could start stripping it away. |
| 28 |
|
| 29 |
That isn't unlike what was done to get rid of the big kernel lock - |
| 30 |
just remove it one instance at a time... |
| 31 |
|
| 32 |
Rich |
Archives