1 |
> On Nov 15, 2014, at 3:57 PM, Matt Turner <mattst88@g.o> wrote: |
2 |
> |
3 |
>> On Thu, Nov 13, 2014 at 7:17 AM, Ian Stakenvicius <axs@g.o> wrote: |
4 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
>> Hash: SHA256 |
6 |
>> |
7 |
>>> On 13/11/14 09:05 AM, Michael Orlitzky wrote: |
8 |
>>>> On 11/13/2014 05:30 AM, Michael Palimaka wrote: |
9 |
>>>> |
10 |
>>>> Suggested policy to get the ball rolling: |
11 |
>>>> |
12 |
>>>> In general, a package must explicitly depend upon what it |
13 |
>>>> directly uses. However, to avoid ebuild complexity and developer |
14 |
>>>> burden there are some exceptions. Packages that appear in the |
15 |
>>>> base system set may be omitted from an ebuild's dependency list |
16 |
>>>> in the following circumstances: |
17 |
>>>> |
18 |
>>>> * C compiler and runtime |
19 |
>>> |
20 |
>>> Specifically sys-devel/gcc and sys-libs/glibc (i.e. what's in |
21 |
>>> @system), or just anything? |
22 |
>> |
23 |
>> I would sincerely hope that nothing in the tree explicitly requires |
24 |
>> gcc as a C compiler. |
25 |
> |
26 |
> You say this, and then mention glibc in the next sentence. Glibc can |
27 |
> only be built with gcc. :) |
28 |
> |
29 |
|
30 |
Sorry, I meant to say nothing other than toolchain-related packages :). Thanks for clarifying for me |
31 |
|
32 |
|
33 |
>> Glibc is a bit different, it may be necessary to explicitly depend on |
34 |
>> it (or use the elibc_glibc flag) if the package can't work with the |
35 |
>> libc alternatives, but ideally |
36 |
> |