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/
