Re: Upgrading rant.
От | Tom Lane |
---|---|
Тема | Re: Upgrading rant. |
Дата | |
Msg-id | 5466.1041553566@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Upgrading rant. (Lamar Owen <lamar.owen@wgcr.org>) |
Ответы |
Re: Upgrading rant.
("Ross J. Reedstrom" <reedstrm@rice.edu>)
Re: Upgrading rant. (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-hackers |
Lamar Owen <lamar.owen@wgcr.org> writes: > So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. It > was very bad. It simply would not build -- I guess it's the gcc 3 > stuff. If you don't know *exactly* why it doesn't build, I don't think you should be blaming us for it. (FWIW, I just tried to build 7.1 branch on RHL 8.0 --- the main problem seems to be that 7.1's configure isn't expecting multiline output from "gcc --version", and it produces a PG_VERSION_STR definition that's missing a trailing quote. There are some other issues, none that look very difficult to fix, all indicative of incompatible changes in either gcc or system include files.) > THIS DOESN'T HAPPEN WITH MySQL. Oh? Do they have a crystal ball that lets them predict incompatible future platform changes? (I'm not very sure I believe your assertion above, anyway. We are painfully aware of our own compatibility issues, but I wonder how many people on this list pay close enough attention to MySQL to know what their version-to-version compatibility track record *really* is.) > I thought the last time through would be the _last_ time through -- > but I also thought I'd be able to build older PostgreSQL packages for > newer dists, which would prevent much of this problem. You could do so if you were willing to track the platform changes. 7.1 isn't hopelessly broken for RHL 8.0, but it's definitely suffering bit rot. Someone would have to expend effort on updating obsolete branches, if we wanted them to keep working in the face of incompatible platform changes. > And I'd love to see someone who has the time to do so (not me) grab > this bull by the horns and make it happen. Well, this is exactly the issue: someone would have to put substantial amounts of time into update mechanisms and/or maintenance of obsolete versions, as opposed to features, performance improvements, or bug fixes. Personally, I feel that if we weren't working as hard as we could on features/performance/bugfixes, the upgrade issue would be moot because there wouldn't *be* any reason to upgrade. So I'm not planning to redirect my priorities. But this is an open source project and every developer gets to set their own priorities. If you can persuade someone to put their time into that, go for it. > And I _know_ some are just going to fingerpoint and blame Red Hat. Any such > replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's > fault we can't do a sane upgrade. I think you're wasting your time trying to hold us to a higher standard of backwards-compatibility than is maintained by the OSes and tools we must sit on top of. regards, tom lane
В списке pgsql-hackers по дате отправления: