Thread: 7.1 RPMs
Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
which will work with Mandrake, or should I keep carrying along my
patches to make the spec file work for now?
How are you planning on packaging the hardcopy docs? They are not yet
available, but will be Real Soon Now :(
- Thomas
Thomas Lockhart wrote: > Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM" > which will work with Mandrake, or should I keep carrying along my > patches to make the spec file work for now? I haven't addressed that as yet. Is it safe to assume that -ffast-math should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math _ever_ a Good Thing for our routines? I can easily enough strip out -ffast-math from the flags for all cases (xarg -n 1 grep -v ffast-math|xargs is your friend....). While I don't plan on following the Mandrake Way WRT repackaging our tarball with bzip2, the source RPM should use whatever compression for the man pages that the buildrootpolicy for that distribution supplies. > How are you planning on packaging the hardcopy docs? They are not yet > available, but will be Real Soon Now :( In the postgresql-docs subpackage, along with the SGML source. The html built docs made from the SGML source is still going into the main tarball, as they are nice and browseable in their standard location. If I release a -1 RPM without the hardcopy, I can release a -2 with.... I have a couple of patches from Trond to integrate, and a decision to make regarding the contribs: should all the contrib tree go into one big RPM (860KB or so),or should each contrib directory get its own RPM (reminiscent of the PM3 binary RPM monster)? One patch from Trond has been duplicated by Karl: which patch allows building as non-root again. There's also a question about the Python client -- it would be good if someone who has downloaded one of the RC RPM's could test that, as I'm not a snake charmer. :-) Also, I need either a standard way to build the java stuff (meaning my own JDK that is reasonably standard by consensus -- kaffe ships with RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to package 7.1 JDBC jars for my packaging pleasure. I'm running low enough on disk space on my devel machines (one of which is a notebook) to make my own JDK a second choice. Oliver, what are doing with the JDBC client? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > In the postgresql-docs subpackage, along with the SGML source. Why would you want to ship the source? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Fri, 13 Apr 2001, Peter Eisentraut wrote: > Lamar Owen writes: > > In the postgresql-docs subpackage, along with the SGML source. > Why would you want to ship the source? For those with SGML tools and viewers, who might like to build hardcopy of their own. Frankly, it was an easy thing to do; had been done; and I saw no real reason to stop doing it. I _does_ take up a little space, however. The SGML source had been distributed as part of the main RPM, prior to 7.1. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> I haven't addressed that as yet. Is it safe to assume that -ffast-math
> should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math
> _ever_ a Good Thing for our routines? I can easily enough strip out
> -ffast-math from the flags for all cases (xarg -n 1 grep -v
> ffast-math|xargs is your friend....).
I believe that there is no room for -ffast-math in PostgreSQL. The
compiler man page says that the option allows the compiler to generate
code which does not conform to IEEE math standards, and istm that we
might consider that as affecting our predictability and portability. The
man page also warns against using -ffast-math and -O together, but I
can't tell if that is a warning to users or a "note to myself" for the
compiler maintainers.
> While I don't plan on following the Mandrake Way WRT repackaging our
> tarball with bzip2, the source RPM should use whatever compression for
> the man pages that the buildrootpolicy for that distribution supplies.
Certainly so for the tarball. However the tarballs are delivered is how
we should use them imho. Why is it an issue for the man pages? They are
uncompressed in our source tarball (? haven't checked) and if we have
them uncompressed in the RPM build area then they get compressed by RPM
somewhere between installation and RPM packaging, right?
> > How are you planning on packaging the hardcopy docs? They are not yet
> > available, but will be Real Soon Now :(
> In the postgresql-docs subpackage, along with the SGML source. The html
> built docs made from the SGML source is still going into the main
> tarball, as they are nice and browseable in their standard location.
> If I release a -1 RPM without the hardcopy, I can release a -2 with....
Great.
> There's also a question about the Python client -- it would be good if
> someone who has downloaded one of the RC RPM's could test that, as I'm
> not a snake charmer. :-)
Not sure about the python stuff, and I don't recall doing anything in
the past on that topic.
> Also, I need either a standard way to build the java stuff (meaning my
> own JDK that is reasonably standard by consensus -- kaffe ships with
> RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to
> package 7.1 JDBC jars for my packaging pleasure. I'm running low enough
> on disk space on my devel machines (one of which is a notebook) to make
> my own JDK a second choice.
In the past I have found that kaffe did not handle enough java code for
my needs, but that was not for the JDBC driver. I am currently using
jikes for my projects, and it produces *nice* code in my experience.
- Thomas
Thomas Lockhart wrote: > I believe that there is no room for -ffast-math in PostgreSQL. The I have placed code in the spec to strip out ffast-math from the CFLAGS. I have not as yet followed Peter's advice on exporting CFLAGS and leaving COPT -- but that's not to say that I won't. > > While I don't plan on following the Mandrake Way WRT repackaging our > > tarball with bzip2, the source RPM should use whatever compression for > > the man pages that the buildrootpolicy for that distribution supplies. > Certainly so for the tarball. However the tarballs are delivered is how > we should use them imho. Exactly. > them uncompressed in the RPM build area then they get compressed by RPM > somewhere between installation and RPM packaging, right? Right. Each distributor can use its own buildrootpolicy -- which handles man page compression, executable stripping, and the like. Not an issue -- but Mandrake historically bzip2's them. > Not sure about the python stuff, and I don't recall doing anything in > the past on that topic. I thought you did up the current build way ... but I could be mistaken. I need to see if the python interface makefile Does the Right Thing now WRT RPM_BUILD_ROOT/DESTDIR processing. The main make stuff now acts sanely inthe presence of RPM_BUILD_ROOT -- well, except the perl interface, but that's a special case. > In the past I have found that kaffe did not handle enough java code for > my needs, but that was not for the JDBC driver. I am currently using > jikes for my projects, and it produces *nice* code in my experience. Jikes is open source, right? I know it is available for Red Hat (ships with it on one of the applications CD's,IIRC.) How does a Jikes-built JDBC sound to people? Ormaybe I don't understand the Java Way well enough to decide. Gotta learn it a little.... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > > In the past I have found that kaffe did not handle enough java code for > > my needs, but that was not for the JDBC driver. I am currently using > > jikes for my projects, and it produces *nice* code in my experience. > > Jikes is open source, right? I know it is available for Red Hat (ships > with it on one of the applications CD's,IIRC.) How does a Jikes-built > JDBC sound to people? Ormaybe I don't understand the Java Way well > enough to decide. Gotta learn it a little.... Jikes is an excellent compiler, but it needs a set of classes to compile against from a JDK. -- Trond Eivind Glomsrød Red Hat, Inc.
Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
If someone wants to come up with an idea for name, i think that the whole Win camp could be seperated also ... pgsql-windows and pgsql-rpm ? as far as newsgroups are concerned, they would both fall under ports: comp.databases.postgresql.ports.linux.rpm comp.databases.postgresql.ports.windows I'm willing to create, as long as ppl are willing to use *shrug* On Sat, 14 Apr 2001, Bruce Momjian wrote: > Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote: > If someone wants to come up with an idea for name, i think that the whole > Win camp could be seperated also ... > pgsql-windows and pgsql-rpm ? > as far as newsgroups are concerned, they would both fall under ports: If that's what you want to do. Although, I'd recommend pgsql-cygwin, lest someone erroneously think we directly support Win32. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
The Hermit Hacker <scrappy@hub.org> writes:
> If someone wants to come up with an idea for name, i think that the whole
> Win camp could be seperated also ...
> pgsql-windows and pgsql-rpm ?
A windows list seems like a good idea. But I'm not sure that a separate
list for RPMs is a good idea. In the first place, it's fuzzy: is it
to be used just for RPM packaging discussion, or is it going to draw
off --- for example --- all bug reports from people who happen to have
installed from RPM instead of source? I suppose the former is intended,
but it's not going to be clear to people. I think we've already got too
many lists with fuzzy boundaries. In the second place, the RPM
packaging discussion is quite sporadic; I think the traffic would be nil
except at times when Lamar is working on new RPMs.
regards, tom lane
On Sat, 14 Apr 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > If someone wants to come up with an idea for name, i think that the whole > > Win camp could be seperated also ... > > > pgsql-windows and pgsql-rpm ? > > A windows list seems like a good idea. But I'm not sure that a > separate list for RPMs is a good idea. In the first place, it's > fuzzy: is it to be used just for RPM packaging discussion, or is it > going to draw off --- for example --- all bug reports from people who > happen to have installed from RPM instead of source? I suppose the > former is intended, but it's not going to be clear to people. I think > we've already got too many lists with fuzzy boundaries. In the second > place, the RPM packaging discussion is quite sporadic; I think the > traffic would be nil except at times when Lamar is working on new > RPMs. That's why I wasn't sure how to classify the RPM one ... I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?
Bruce Momjian writes: > Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. The traffic naturally peaks around release time, and this time especially because yours truly messed up the whole build system that the packagers were so careful to work around. I trust that in a few weeks we'll enter a new quiet period. My vote is that technical packaging discussions should go on -hackers just like a makefile discussion. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Bruce Momjian writes: > > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The traffic naturally peaks around release time, and this time especially > because yours truly messed up the whole build system that the packagers > were so careful to work around. I trust that in a few weeks we'll enter a > new quiet period. My vote is that technical packaging discussions should > go on -hackers just like a makefile discussion. > OK, it was just an idea. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 14 Apr 2001, Peter Eisentraut wrote: > Bruce Momjian writes: > > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The traffic naturally peaks around release time, and this time > especially because yours truly messed up the whole build system that > the packagers were so careful to work around. I trust that in a few > weeks we'll enter a new quiet period. My vote is that technical > packaging discussions should go on -hackers just like a makefile > discussion. Why not a "pgsql-build", or something like that, list? Where build/make file discussions can take place? Vs server issues? I'd really like to find some way of reducing traffic on -hackers like we did with -interfaces ... if we can come up with a good list for it ... pgsql-build (or a better name?) could be for RPM discussions, just as easy as Makefile/Configure discussions ...
The Hermit Hacker <scrappy@hub.org> writes:
> I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?
Yes, that's probably better than pgsql-windows ...
regards, tom lane
The Hermit Hacker writes: > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? We have pgsql-ports, which isn't seeing too much traffic as it is. Seems like the cygwin people hang out there anyway. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Sat, 14 Apr 2001, The Hermit Hacker wrote: > On Sat, 14 Apr 2001, Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > Do we need to start thinking about an RPM mailing list? Seems there is > > > lots of traffic. > > > > The traffic naturally peaks around release time, and this time > > especially because yours truly messed up the whole build system that > > the packagers were so careful to work around. I trust that in a few > > weeks we'll enter a new quiet period. My vote is that technical > > packaging discussions should go on -hackers just like a makefile > > discussion. > > Why not a "pgsql-build", or something like that, list? Where build/make > file discussions can take place? Vs server issues? I'd really like to > find some way of reducing traffic on -hackers like we did with -interfaces > ... if we can come up with a good list for it ... > > pgsql-build (or a better name?) could be for RPM discussions, just as easy > as Makefile/Configure discussions ... How 'bout pgsql-hackers-rpm. Because the make/config stuff can impact so many different parts of PostgreSQL, that stuff should probably remain on hackers. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Sat, 14 Apr 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > We have pgsql-ports, which isn't seeing too much traffic as it is. Seems > like the cygwin people hang out there anyway. Ya, well, there is alot of traffic on -hackers that should probably be over there anyway *shrug*
On Sat, 14 Apr 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > Yes, that's probably better than pgsql-windows ... Done ...
> The Hermit Hacker <scrappy@hub.org> writes: > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > Yes, that's probably better than pgsql-windows ... But then again, the comment this is more properly done on ports makes sense. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
The Hermit Hacker writes: > If someone wants to come up with an idea for name, i think that the whole > Win camp could be seperated also ... > > pgsql-windows and pgsql-rpm ? There seem to be a lot of Linux users, too. How about a new mailing list? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote: > The traffic naturally peaks around release time, and this time especially > because yours truly messed up the whole build system that the packagers > were so careful to work around. Now, Peter. The build, IMHO, is much better than before -- if anything, the fact that we had to change as much as we did shows that the previous build system, no offense intended to anyone who worked on it :-), wasn't 'packaging friendly.' I ripped out more special treatment than I had to put in. The less code in the spec, the better the spec (and the better the package). Now I just have to get the Python build version-agnostic and using the regular build -- even if I have to dink with the makefiles myself. I think the perl build, due to its two-stage needs, will remain the special case that it is. > I trust that in a few weeks we'll enter a > new quiet period. My vote is that technical packaging discussions should > go on -hackers just like a makefile discussion. I tend to agree -- but at the same time I'm easy to get along with in that regard. Packaging envelopes the whole program -- I must see the forest that the -hackers group has built out of trees. And I have to know some details of the trees occasionally. I'm sure Oliver would agree. And, to let everyone know, I'm having a blast doing this. And I'm glad my work schedule eased up some in the last month so I could put some time to this task. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > In the past I have found that kaffe did not handle enough java code for
> > my needs, but that was not for the JDBC driver. I am currently using
> > jikes for my projects, and it produces *nice* code in my experience.
> Jikes is open source, right? I know it is available for Red Hat (ships
> with it on one of the applications CD's,IIRC.) How does a Jikes-built
> JDBC sound to people? Ormaybe I don't understand the Java Way well
> enough to decide. Gotta learn it a little....
For the RPM, you should be able to build JDBC with whatever compiler
produces reliable, quality code. jikes is one good candidate imho.
Not sure if the configure info for JDBC looks for choices of compiler,
or if you can specify the compiler for the build. I can look into it,
but am not sure how one interacts with ant (we are using ant to do the
Java build now, right??) or if ant handles it already.
- Thomas
> Do we need to start thinking about an RPM mailing list? Seems there is
> lots of traffic.
The delete key is your friend. So is procmail, if you just can't stand
to see the letters "R", "P", and "M" too close together ;)
I'm not a big fan of the trend to fork off a mailing list anytime more
than a few messages on a single topic come through. The synergy and
cross-pollination that we get by having us all see various topics wrt
development far outweigh the minor annoyance to some on having to delete
topics they don't find interesting.
As an example, RPM building is only a part of the general packaging of
PostgreSQL, but it illustrates issues which anyone touching
configuration or Makefiles should be aware of. So forcing "those Linux
people" onto some specialty list weakens the knowledge base we all could
draw from.
All imho of course...
- Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'm not a big fan of the trend to fork off a mailing list anytime more
> than a few messages on a single topic come through. The synergy and
> cross-pollination that we get by having us all see various topics wrt
> development far outweigh the minor annoyance to some on having to delete
> topics they don't find interesting.
That's my feeling also. There's a considerable downside to fragmenting
the PG discussions across multiple lists: not only that people may miss
stuff that they should have seen, but also the increased probability
that messages will be sent to the wrong lists to begin with.
We should only split off new lists when the volume gets to the point of
being absolutely intolerable --- which the RPM stuff is not. The Cygwin
stuff might be sufficiently specialized that it can survive as a
separate list, but I thought that was a marginal call at best.
regards, tom lane
On Sun, 15 Apr 2001, Thomas Lockhart wrote: > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The delete key is your friend. So is procmail, if you just can't stand > to see the letters "R", "P", and "M" too close together ;) > > I'm not a big fan of the trend to fork off a mailing list anytime more > than a few messages on a single topic come through. The synergy and > cross-pollination that we get by having us all see various topics wrt > development far outweigh the minor annoyance to some on having to delete > topics they don't find interesting. > > As an example, RPM building is only a part of the general packaging of > PostgreSQL, but it illustrates issues which anyone touching > configuration or Makefiles should be aware of. So forcing "those Linux > people" onto some specialty list weakens the knowledge base we all could > draw from. > > All imho of course... agreed, that's why I was kinda thinking maybe some sort of 'build' list ... something that deals with configure, makefile and packaging issues ...
Bruce Momjian wrote: > > Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. IIRC, this question was asked about 6 months ago, and the answer was RPM should be discussed on PostgreSQL-Ports. On the other hand, it seems in practice most people are unaware of this, and do in fact is general or devel. Maybe if there were PostgreSQL-RPM as an alias to PostgreSQL-Ports? Or a separate list, I don't mind either way, but it's pretty clear to me that currently there is alot of misdirected traffic.. -- Karl