| 1 |
On 06/30/2015 11:25 AM, Michael Orlitzky wrote: |
| 2 |
> On 06/30/2015 02:12 PM, Zac Medico wrote: |
| 3 |
>> |
| 4 |
>>> Suppose ten years from now everything is written in Go. I have 500 |
| 5 |
>>> statically linked Go packages on my system, all of whose dependencies |
| 6 |
>>> were built and compiled-in at install time. Now someone finds a remote |
| 7 |
>>> root vulnerability in the go-openssl library. I know some of the |
| 8 |
>>> packages I have installed were built against it. What do I do? |
| 9 |
>> |
| 10 |
>> Use slot-operator := deps, together with the emerge --with-bdeps=y |
| 11 |
>> option. Then, if you bump the sub-slot of the go-openssl library, all of |
| 12 |
>> your go packages that have it in DEPEND with a slot-operator := |
| 13 |
>> dependency will be rebuilt automatically. |
| 14 |
>> |
| 15 |
> |
| 16 |
> Right, and now what if go-openssl was built on-the-fly 500 times and |
| 17 |
> there's no package for it? |
| 18 |
|
| 19 |
Yeah that's obviously sub-optimal, and it's the reason why I created the |
| 20 |
dev-go/* ebuilds. However, we may want to distinguish between libraries |
| 21 |
that would only have a single consumer and libraries that would have |
| 22 |
multiple consumers. Using the same rules regardless of the number of |
| 23 |
consumers is not necessarily optimal. |
| 24 |
-- |
| 25 |
Thanks, |
| 26 |
Zac |
Archives