Re: RPM source files should be in CVS (was Re: psql -l)

On Friday 20 July 2001 12:30, Peter Eisentraut wrote:
> Lamar Owen writes:
> > 8       migration-scripts.tar.gz

> No tar or gz files in CVS.

That's easy enough to fix.

> > 4       postgresql-7.1.plperl.patch
> > 4       postgresql-7.1.s390x.patch

> No patches in CVS.

Then the configure system needs to support an optional FHS-compliant mode, as
well as alternative builds for plperl.... :-)  The biggest patching by far is
in the regression tests, which really are not designed to live outside the
source tree, but can be munged into shape fairly easily.

Why no patches in CVS?  How do you propose to handle the differences,
particularly if the debian stuff is placed in CVS (that diff is 10,884 lines
and 362,119 bytes in length)?

> > 4       postgresql-dump.1.gz

> What's wrong with pg_dump?

It only uses the current executables.  After an 'rpm -U' older executables
are kept around by the server subpackage's %pre scriptlet, and
postgresql-dump/rh-dump massage the ld envvars to force execution of those
binaries to take a dump of the old database.  If a good upgrade path existed,
this kludge would be unnecessary.

> > 8       postgresql.init

> We already have one of those.

That is too generic.  This one is rather simple and is designed to work well
in the FHS-compliant environment, without lots of guessing where things are
-- the RPMset has a rigid structure where no guesswork is really necessary
(except for the location of documentation, which changes from dist to dist).
This one also automatically initdb's for you in the correct (for the RPMset)
place and with saving of locale values, etc, for later use, making sure to
start the postmaster with the same locale as initdb was executed with...
amongst other things.

If an older database is found, a message pointing to the README.rpm-dist is
supplied, and postmaster is not started.

> See, if we want to get into the packaging business for real, then there
> should not be any patches or extra programs or extra features distributed.
> Fixes should be incorporated, not archived.

Then there needs to be a little more willingness to accept patches which
provide FHS-compliance (as an option).  So your opinion is that we're not
really in the packaging business, right? Or am I misunderstanding that?

Should package-specific programs be distributed as part of the tarball that
everyone downloads?  Not likely.

Being in CVS != being in the tarball(s), does it?

And having the spec file (which I inadvertently omitted above -- it's another
30k or so) in CVS would be a real boon to many.

> Then again, there are at least six other packaging efforts out there which
> come with yet another set of patches and what not so I see this getting
> messy.

Six? I know of PLD's difference, and SuSE's difference -- but both of them
have synced with our set periodically.  There's four others?  Or are you
referring to non-RPM packages, such as Cygwin, Debian, and (four others)?

Hey, I'm fine either way -- it was Tom's suggestion, in order to help all the
developers out, not just me.  It matters little to me if it's in the
postgresql.org CVS or not -- but it could help him and others track stuff
down (recursive grep with error messages, for instance).

Point being that bug reports that involve changes to the core code by
packages are happening, and confusion has resulted.  A solution needs to be
found -- and, frankly, the packages aren't going away.

I'm going to go back two and a half years and re-read the stuff that lead up
to me fielding this particular portion of our development, to refresh my
perspective.....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11