Albretch Mueller wrote: > be quite a bit stupidly risky. I am thinking here mostly about running > servers >
on servers, I am VERY selective about what gets updated with portage. I have even added package versions to portage.mask in order to keep things from upgrading (such as php4 vs php5). Also, reading the ChangeLogs are very important for a server install. There was talk at one point to introduce a "server portage tree", which would probably have less bleeding edge packages. In my opinion, it would at the very least have immediate critical updates, and a 60 or 90 day delay from new ebuilds to migrate to "stable" ebuilds. The who or why or how regarding critical patch backporting is another can of worms that I have no idea where to start. Would I use such a tree? Maybe. If I did, it would be for a very specific machine which I knew would have little updates. "If it ain't broke, don't fix it." - those machines. > 1) choose the most Linux stable kernel > I would think this is mostly subjective, based on your driver selection. Some configurations of hardware may talk better to newer versions of drivers (I have a couple of wireless cards where this is very true). > 2) choose the most stable applications' versions that would dance > well after 1)'s music > again, I think this is very subjective. For applications, it's mainly due to package age. If it's old and doesn't have critical security patches, then it's stable. There are plenty of distros which actually BACKPORT security patches to OLD packages. These same groups of distros don't always agree which version is the stable one. > 3) check all "most stable" dependencies > again. you're trying to deduce "most stable" via some metric of which there is no standard nor defacto method. Gentoo, from what I've seen uses the 30-day metric. Once an updated ebuild has been released into the "production" portage tree, it takes at least 30 days for that ebuild to migrate to "stable" in x86 that's ~x86 to x86 for ACCEPT_KEYWORDS or /etc/portage/package.keywords. I'm sure there are other factors which could delay that to greater than 30 days. > I think this is doable. To me it is just a case of bridging cultures. > You could for example cheat/use the list of packages and dependencies > of the most stable debian release > I think you're asking a lot of the current portage and package maintainers. Having a portage tree designed with this layout would require some type of decision making and possible backporting of code to older versions. Those two things bother me on two levels: 1) I like gentoo, because it gives me plenty of choices. If I choose to shoot my box in the harddrive by installing package 123, then so be it. It's my harddrive (or one I control). A "stable tree" takes control away from me due to another body making "saner" decisions. In reality, if I had to choose between this supposed "stable tree" or the "original tree", I'm probably going to choose the original. This is one of the reasons I stopped installing redhat - even on some production machines. 2) Without a rather large QA group, I'm not sure how much better a backport or critical patches would be compared to the actual updated version from the upstream. There's LOTS of packages, and the upstream developers for most package understand their packages better than a maintainer. I also feel this type of setup would be putting a bit more liability on the gentoo maintainers that they might be prepared to take on. Especially the ones that don't get paid :) I'd also like to point out that not every linux distro has to be an EVERYTHING or EVERYONE distro. I really don't think it's possible really, as the very nature of making one distro EVERY-whatever imposes restrictions and limitations that some people will shy away from. -- [EMAIL PROTECTED] mailing list
