1 |
On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: |
2 |
> On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht |
3 |
> <nicolas.s-dev@×××××××.net> wrote: |
4 |
> > Portage should support a way to expose ALL the conditions for a software |
5 |
> > to work and update installed libraries to match the requirements. |
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 |
To make it simple, this is almost irrelevant IMHO. It won't happen |
15 |
because we are talking about patches required as dependency excluding |
16 |
other patches required as dependency on the same sources. |
17 |
|
18 |
IOW, we must notice that we would need multiple *installed* versions |
19 |
ONLY IF a dependency requirement is not met AND that this requirement is |
20 |
*excluding* one of the current gcc requirements. So, when they are |
21 |
non-compatible themselves in some way at the source level. |
22 |
|
23 |
On top of that, this would have to be an issue that has to be handled by |
24 |
the software devs. |
25 |
|
26 |
> Second, good luck dealing with security patches and bugfixes. You now |
27 |
> have 300 copies of glibc to update, and since your list of |
28 |
> dependencies stated that you have 14 patches and no others you now |
29 |
> need to update the 300 other packages to use the newer version of |
30 |
> glibc. |
31 |
> |
32 |
> The current Gentoo way is far more limiting, but by having a single |
33 |
> version of glibc with a single policy around versioning/etc packages |
34 |
> don't have to micromanage what they depend on. |
35 |
|
36 |
Well, I wouldn't worry about that because having 300 versions of gcc (or |
37 |
any other package) is not the purpose. But it is a very good thing to |
38 |
restart the thread from patches handling like you did since it is the |
39 |
basis of software updates. |
40 |
|
41 |
When it comes to building a real and flexible meta-distribution (after |
42 |
all, this thread is all this issue), it is nice to have the packages |
43 |
management tools working for you. |
44 |
|
45 |
Also, it is good to keep in mind that everybody in the chain from the |
46 |
software developers to the users including fork developers, |
47 |
package-distro maintainers, sysadmin and the final users might want to |
48 |
tune their systems at some point. They are all some kind of "forkers" |
49 |
with the current Gentoo. |
50 |
|
51 |
Starting from there, the tools should not only allow them to do what |
52 |
they want but also help them in that task WHITOUT forking. If it's not |
53 |
the case, you end up with overlays or similar technics whose come which |
54 |
much more damaging problems in practice. |
55 |
|
56 |
|
57 |
All distributions manage vanilla sources + patches (including security |
58 |
patches and bugfixes). We start from vanilla with compilation options. |
59 |
Each one is declared so they are enabled/disabled easily (use flags...). |
60 |
Would it be that hard to declare if the patch add/remove/change a |
61 |
dependency? I don't think so. |
62 |
|
63 |
Now comes the series of patches management. Would it be hard to have the |
64 |
tools allowing to tune the series of patches that are going to be |
65 |
applied? I don't think so, either. |
66 |
|
67 |
Would it be hard to have the tools allow each role to tune/configure the |
68 |
system for both useflags and series of patches? Neither, we know how to |
69 |
do that kind of things since decades. |
70 |
|
71 |
So, when there are security fixes or bugfixes we don't need anything |
72 |
much crazy to handle them: the management of series of patches is |
73 |
already supported of the tools. |
74 |
|
75 |
|
76 |
Today, ebuilds don't even let a chance for an admin to apply a series of |
77 |
patches to the vanilla/distro-maintainer sources without having to |
78 |
rewrite/fork the ebuild. Whatever it is critical for them. The lone |
79 |
option is to fork+overlay. This is a serious issue FMPOV. |
80 |
|
81 |
> If NixOS/etc have found a better solution I'm all ears, but it is hard |
82 |
> to tell based on the info on their website. It seems hard to me to |
83 |
> allow so much diversity in dependencies without basically having every |
84 |
> package on your system running in its own container (thus consuming a |
85 |
> lot more RAM), and while managing security updates in a sane way. |
86 |
|
87 |
I don't know about NixOS/etc. I'll look at that. |
88 |
|
89 |
About containers, they are usefull for solving other problems like |
90 |
testing, deployement or required isolation, IMO. |
91 |
|
92 |
-- |
93 |
Nicolas Sebrecht |