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