1 |
On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht |
2 |
<nicolas.s-dev@×××××××.net> wrote: |
3 |
> Portage should support a way to expose ALL the conditions for a software |
4 |
> to work and update installed libraries to match the requirements. |
5 |
> |
6 |
|
7 |
This sounds nice in principle, but making it work is not trivial. |
8 |
|
9 |
Suppose my package works with gcc-1.2.3.4 with a list of 14 specific |
10 |
patches and no others, and glibc-1.2.3.4 with another list of 14 |
11 |
patches and no others. Now suppose 300 other packages have similar |
12 |
requirements. |
13 |
|
14 |
First, expressing that without losing your mind is going to be VERY |
15 |
painful. You basically end up having to use content-hashed packages |
16 |
or something like that. You also end up with 300 copies of glibc in |
17 |
RAM and so on. |
18 |
|
19 |
Second, good luck dealing with security patches and bugfixes. You now |
20 |
have 300 copies of glibc to update, and since your list of |
21 |
dependencies stated that you have 14 patches and no others you now |
22 |
need to update the 300 other packages to use the newer version of |
23 |
glibc. |
24 |
|
25 |
The current Gentoo way is far more limiting, but by having a single |
26 |
version of glibc with a single policy around versioning/etc packages |
27 |
don't have to micromanage what they depend on. |
28 |
|
29 |
If NixOS/etc have found a better solution I'm all ears, but it is hard |
30 |
to tell based on the info on their website. It seems hard to me to |
31 |
allow so much diversity in dependencies without basically having every |
32 |
package on your system running in its own container (thus consuming a |
33 |
lot more RAM), and while managing security updates in a sane way. |
34 |
|
35 |
-- |
36 |
Rich |