Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

Peter Eisentraut wrote:
> 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.)

I know alot of people don't like LSB/FHS, but, like it or not, I have to
work with it. And, many many thanks for putting in the work on the
configuration as you have.

> > * 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.

Like the TRS-80 model III, whose TRSDOS 1.3 could not read the TRS-80
Model I's disks, written on TRSDOS 2.3 (TRSDOS's versioning was
absolutely horrendous). TRSDOS 1.3 included a CONVERT utility that
could read files from the old filesystem.

I'm sure that the newer distributions using ReiserFS as the primary
filesystem will include legacy Ext2/3 support, at least for read-only,
for many versions to come.

And that's my big beef -- a newer version of PostgreSQL can't even
pg_dump an old database. If that single function was supported, I would
have no problem with the upgrade whatsoever.

> > * 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."

Yes, and I do just that. Regression testing is a regular part of my
build process here.

> RPM packages usually don't work very
> well on systems that are not exactly like the one they were built on

Boy, don't I know it.....~;-/

> Getting the regression tests to work from anywhere is not very hard, but
> it's not the most interesting project for most people. :-)

I know. I'll probably do it myself, as that is something I _can_ do.

> > 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.

RPM is getting it's .so dependency list straight from the mouth of the
dynamic loader itself. RPM uses shell scripts, customizable for each
system on which RPM runs, to determine the automatic dependencies --
those shell scripts run the dynamic loader to get the list of requires.
So, the dynamic loader itself is providing the list.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11