Gentoo Archives: gentoo-user

From: Billy Holmes <billy@××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] (more about) portage issues and simple/basic hacks/ideas about how to deal with them ...
Date: Mon, 19 Nov 2007 05:14:18
In Reply to: [gentoo-user] (more about) portage issues and simple/basic hacks/ideas about how to deal with them ... by Albretch Mueller
1 Albretch Mueller wrote:
2 > be quite a bit stupidly risky. I am thinking here mostly about running
3 > servers
4 >
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.
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.
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.
22 > 1) choose the most Linux stable kernel
23 >
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).
29 > 2) choose the most stable applications' versions that would dance
30 > well after 1)'s music
31 >
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.
39 > 3) check all "most stable" dependencies
40 >
42 again. you're trying to deduce "most stable" via some metric of which
43 there is no standard nor defacto method.
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.
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 >
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:
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.
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 :)
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