Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
От | Peter Eisentraut |
---|---|
Тема | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) |
Дата | |
Msg-id | Pine.LNX.4.21.0010281643291.763-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?) (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-hackers |
Lamar Owen writes: > Getting the installation that 'make install' spits out massaged into > an FHS compliant setup is the majority of the RPM's spec file. ./configure --prefix=/usr --sysconfdir=/etc Off you go... (I'll refrain from commenting further on the FHS.) > * Upgrades that don't require an ASCII database dump for migration. Let me ask you this question: When any given RPM-based Linux distribution will update their system from ext2 to, say, ReiserFS across the board, how are they going to do it? Sincere question. > * A less source-centric mindset. Let's see, how to explain? The > regression tests are a good example. You need make. You need the source > installed, configured, and built in the usual location. This is not an excuse, but almost every package behaves this way. Test suites are designed to be run after "make all" and before "make install". When you ship a binary package then you're saying to users "I did the building and installation (and presumably everything else that the authors recommend along the way) for you." RPM packages usually don't work very well on systems that are not exactly like the one they were built on, so this seems to be a fair assumption. Getting the regression tests to work from anywhere is not very hard, but it's not the most interesting project for most people. :-) > I think I may have a solution for the library versioning problem. > Rather than symlink libpq.so->libpq.so.2->libpq.so.2.x, I'll copy > libpq.so.2.1 to libpq.so.2 and symlink libpq.so to that. I'd still claim that if RPM thinks it's smarter than the dynamic loader, then it's broken. All the shared libraries on Linux have a symlink from more general to more specific names. PostgreSQL can't be the first to hit this problem. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: