1 |
Albretch Mueller wrote: |
2 |
> be quite a bit stupidly risky. I am thinking here mostly about running |
3 |
> servers |
4 |
> |
5 |
|
6 |
on servers, I am VERY selective about what gets updated with portage. I |
7 |
have even added package versions to portage.mask in order to keep things |
8 |
from upgrading (such as php4 vs php5). Also, reading the ChangeLogs are |
9 |
very important for a server install. |
10 |
|
11 |
There was talk at one point to introduce a "server portage tree", which |
12 |
would probably have less bleeding edge packages. In my opinion, it would |
13 |
at the very least have immediate critical updates, and a 60 or 90 day |
14 |
delay from new ebuilds to migrate to "stable" ebuilds. The who or why or |
15 |
how regarding critical patch backporting is another can of worms that I |
16 |
have no idea where to start. |
17 |
|
18 |
Would I use such a tree? Maybe. If I did, it would be for a very |
19 |
specific machine which I knew would have little updates. "If it ain't |
20 |
broke, don't fix it." - those machines. |
21 |
|
22 |
> 1) choose the most Linux stable kernel |
23 |
> |
24 |
|
25 |
I would think this is mostly subjective, based on your driver selection. |
26 |
Some configurations of hardware may talk better to newer versions of |
27 |
drivers (I have a couple of wireless cards where this is very true). |
28 |
|
29 |
> 2) choose the most stable applications' versions that would dance |
30 |
> well after 1)'s music |
31 |
> |
32 |
|
33 |
again, I think this is very subjective. For applications, it's mainly |
34 |
due to package age. If it's old and doesn't have critical security |
35 |
patches, then it's stable. There are plenty of distros which actually |
36 |
BACKPORT security patches to OLD packages. These same groups of distros |
37 |
don't always agree which version is the stable one. |
38 |
|
39 |
> 3) check all "most stable" dependencies |
40 |
> |
41 |
|
42 |
again. you're trying to deduce "most stable" via some metric of which |
43 |
there is no standard nor defacto method. |
44 |
|
45 |
Gentoo, from what I've seen uses the 30-day metric. Once an updated |
46 |
ebuild has been released into the "production" portage tree, it takes at |
47 |
least 30 days for that ebuild to migrate to "stable" in x86 that's ~x86 |
48 |
to x86 for ACCEPT_KEYWORDS or /etc/portage/package.keywords. I'm sure |
49 |
there are other factors which could delay that to greater than 30 days. |
50 |
|
51 |
> I think this is doable. To me it is just a case of bridging cultures. |
52 |
> You could for example cheat/use the list of packages and dependencies |
53 |
> of the most stable debian release |
54 |
> |
55 |
|
56 |
I think you're asking a lot of the current portage and package |
57 |
maintainers. Having a portage tree designed with this layout would |
58 |
require some type of decision making and possible backporting of code to |
59 |
older versions. Those two things bother me on two levels: |
60 |
|
61 |
1) I like gentoo, because it gives me plenty of choices. If I choose to |
62 |
shoot my box in the harddrive by installing package 123, then so be it. |
63 |
It's my harddrive (or one I control). A "stable tree" takes control away |
64 |
from me due to another body making "saner" decisions. In reality, if I |
65 |
had to choose between this supposed "stable tree" or the "original |
66 |
tree", I'm probably going to choose the original. This is one of the |
67 |
reasons I stopped installing redhat - even on some production machines. |
68 |
|
69 |
2) Without a rather large QA group, I'm not sure how much better a |
70 |
backport or critical patches would be compared to the actual updated |
71 |
version from the upstream. There's LOTS of packages, and the upstream |
72 |
developers for most package understand their packages better than a |
73 |
maintainer. I also feel this type of setup would be putting a bit more |
74 |
liability on the gentoo maintainers that they might be prepared to take |
75 |
on. Especially the ones that don't get paid :) |
76 |
|
77 |
|
78 |
I'd also like to point out that not every linux distro has to be an |
79 |
EVERYTHING or EVERYONE distro. I really don't think it's possible |
80 |
really, as the very nature of making one distro EVERY-whatever imposes |
81 |
restrictions and limitations that some people will shy away from. |
82 |
-- |
83 |
gentoo-user@g.o mailing list |