Thus, Les Mikesell at Tue Oct 30 12:48:41 2007 inscribed: > Anders Karlsson wrote: >> Thus, Les Mikesell at Mon Oct 29 23:45:49 2007 inscribed: [snip] >>> That's a possibility, but rarely the case except perhaps for the >>> Gnome/KDE environments themselves. Usually it is possible to build >>> current packages on older RHEL versions, but then you have to maintain >>> them yourself. >> Let me see if I have understood this right. You look at subversion or >> dovecot in RHEL5, and you can determine by just looking at the version >> number that they are insufficient for your needs, even if they were >> suitable five months earlier, when RHEL5 was just released? > > Not RHEL5, RHEL4 which is just barely middle-aged. Even so, due to the fact that Red Hat backport features and fixes, you can not simply look at the version number to determine if the package is "out of date" or not. >> That, to me at least, would indicate that you have totally failed to >> understand the purpose of RHEL and the value that it provides to >> Enterprise customers. > > There is much value in not having to update an OS and all the system > libraries for several years and if the machine runs fine there should be no > need to replace device drivers just to get a non-beta dovecot. Why would you need to replace device drivers if all you need to update is Dovecot? Dovecot does not have a dependency on the kernel. It is fully supported to take RHEL4 GA, install it, and then up2date dovecot to latest released through RHN. If you are happy with that system, and you do not care for any of the errata and enhancements released later, your system is still supported. You'd be encouraged to update some packages if there are security vulnerabilities, but it's up to you if you want to or not. Support policy however is that if a later released version of a package contain a fix for the issue you report (should you report one) you'd be told to update that package, and its dependencies, to the version that contain the fix. >> It also would indicate that you do not >> understand how Red Hat maintain each release of RHEL (although you are >> in good company there, as some customers don't understand that either >> to start with). > > I do understand it - and I even like it for most server software because > that has been feature-complete for years now. I was pointing out dovecot > and subversion as rare exceptions on the server side just because of the > progress they have made since the RHEL4 cut. On the desktop, though, > everything is improving rapidly - but that still doesn't mean I want to > have to replace working device drivers to get a new firefox. And if you file RFE's (feature requests) you may get some of those new features and functionality backported as well. We're not psychic you know, you'd actually have to tell Red Hat that there is a feature you'd want to be considered for inclusion. And again, firefox has to my knowledge not got a dependency on the kernel. You can take Firefox from the upcoming RHEL 4.6 and run that on an otherwise unmodified RHEL4GA. No problem. Or maybe you mean you want to take Firefox from RHEL5, and run it on RHEL AS 2.1 as a supported setup? -- Anders Karlsson <anders@xxxxxxxxxxxxxx> All-Round Linux Tinkerer & RHCE -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
