Thread: Re: RPM source files should be in CVS (was Re: psql -l)
On Friday 20 July 2001 12:03, Bruce Momjian wrote: > > The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really > > need to investigate this more closely.... > Can you research that? Why are they doing it? It looks like the updated intarray from Oleg. The diff between what is in the 7.1.2 tarball (which is the same as what is in current CVS) is 26K (the whole intarray directory du's at 192K), and appears to be extensive in nature, with a warning that this is _only_ for PostgreSQL 7.1 and above. Diff to 7.1.2 attached. Oleg announced the new intarray in this message: http://fts.postgresql.org/db/mw/msg.html?mid=120655 and there was discussion following. But I don't see this version in CURRENT CVS??? Hmmm.... I don't see the README changes in current CVS, but I do see the code changes.... The contrib support in the RPMset is fairly new, and Trond made this change that I synced in place. Should I not ship the updated intarray? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Attachment
Lamar Owen writes: > The RPM additions are: > 56 contrib-intarray.tar.gz > 4 file-lists.tar.gz > 8 migration-scripts.tar.gz No tar or gz files in CVS. > 4 postgresql-7.1.plperl.patch > 4 postgresql-7.1.s390x.patch No patches in CVS. > 4 postgresql-bashprofile Not sure what's in there exactly, so I can't comment. > 4 postgresql-dump.1.gz What's wrong with pg_dump? > 8 postgresql.init We already have one of those. > 4 rh-pgdump.sh See above. > 8 rpm-pgsql-7.1.patch See above. 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 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. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
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
Lamar Owen <lamar.owen@wgcr.org> writes: > Oleg announced the new intarray in this message: > http://fts.postgresql.org/db/mw/msg.html?mid=120655 and there was > discussion following. But I don't see this version in CURRENT CVS??? I believe the state of play is that we have some catalog-changing work to do to support GIST (ie, make "haskeytype" work cleanly), and merging the updated intarray code is on hold until that gets done --- hopefully, early next month. We're probably not exactly in sync with what Oleg has, but I'm not worried about it until the GIST dust settles. I dunno whether it makes sense to be shipping the updated intarray code with 7.1; does it work properly in 7.1? Ask Oleg ... regards, tom lane
Lamar Owen <lamar.owen@wgcr.org> writes:
> 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.
Peter has already done good work in making it possible to build outside
the source tree. ISTM that it would make logical sense to allow
regression tests to be run outside the source tree as well, as long as
the changes don't break the existing procedures. I have not looked at
your patches in this area --- what do they need to do, exactly?
> Being in CVS != being in the tarball(s), does it?
Yes. When this was discussed last time, I think the conclusion was that
packaging scripts should be in a different cvs module from the core
sources.
I think there are really two separate discussions going on here: one is
whether we shouldn't try harder to roll some of the RPMset diffs back
into the main sources, and the other is how we can make information
about some of the popular packages more readily visible/available to the
developers. Peter's stance on the latter seems to be "go look at the
packagers' sites", which is defensible, but that's the current approach
and I think it's not working. Leastwise I sure have no idea what's in
the packages. If I can pull down one additional CVS module from hub.org
and include that in my Postgres glimpse searches, I am actually likely
to expend that much effort, and as a result will be a lot better
informed.
> 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.
Exactly.
regards, tom lane