| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 13/11/14 10:17 AM, Ian Stakenvicius wrote: |
| 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 |
| 12 |
>>> developer burden there are some exceptions. Packages that |
| 13 |
>>> appear in the base system set may be omitted from an ebuild's |
| 14 |
>>> dependency list 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 |
| 23 |
> requires gcc as a C compiler. |
| 24 |
> |
| 25 |
> Glibc is a bit different, it may be necessary to explicitly depend |
| 26 |
> on it (or use the elibc_glibc flag) if the package can't work with |
| 27 |
> the libc alternatives, but ideally [...] |
| 28 |
|
| 29 |
... we shouldn't be depending on the specific libc implementation |
| 30 |
-----BEGIN PGP SIGNATURE----- |
| 31 |
Version: GnuPG v2 |
| 32 |
|
| 33 |
iF4EAREIAAYFAlRky8wACgkQ2ugaI38ACPBEEwD+JmErQK2aUPcYsZY6e55lWYfO |
| 34 |
oenrhAK3S4bKX8CdOWoA/1NKBesQnsv6e8KEwPEQrHlQO3DcCA/DVVWPWjUSVCjo |
| 35 |
=+Web |
| 36 |
-----END PGP SIGNATURE----- |
Archives