Thread: 7.2 RPMs
I just took a dreadful look at the RPMs. I've managed to build something
that resembles a 7.2 package, but there are a number of things that we
should talk about so this ends up being useful.
* The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
installed whenever Tk support is configured (which is correct, IMO).
Maybe this is just a legacy item?
* I removed the {plperl} parameter, because PL/Perl now builds by default
on Linux. Should plperl continue to stay its own package? I'd say yes,
because you don't need in on every client.
* Related to previous, the tcl package currently includes client and
server components. I'd say this is more useful as two separate packages.
* Similar issues with PL/Python
* Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is
in -tcl? What about libpgtcl.h? Currently, the -devel package has an
implicit dependency on Tcl, which should probably not be there.
* How long do we want to keep the libpq.so.2.0 symlink?
* I fail to understand the motivation behind the way the -contrib package
is done. You seem to be installing the source code. I scrapped that and
installed the binaries the way it was designed to be.
* The -docs package is misleading. Maybe it should be called -docs-devel
or something. However, I'm having a hard time understanding how people
can make use of this.
* I request that rh-pgdump.sh and postgresql-dump be renamed to something
that conveys a semantic difference from pg_dump. Possibly, these files
should not be installed into /usr/bin if they're not general purpose.
* What about the JDBC driver? I think the driver should be compiled in
place by whatever JDK the build system provides.
* Start thinking about how to package National Language Support.
* Lot's of dependencies failing to be declared.
There are also a number of plain bug fixes that need to be integrated.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote: > <snip> > * What about the JDBC driver? I think the driver should be compiled in > place by whatever JDK the build system provides. Don't know about the rest of this stuff, but I totally agree here. There should be a dependancy on Ant and some kind of JDK, and it should compile the driver specifically. This way the user I reckon the user is WAY more likely to have something which works well for them. Bumped into a problem with this just over a week ago. Regards and best wishes, Justin Clift <snip> > -- > Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Peter Eisentraut <peter_e@gmx.net> writes:
> I just took a dreadful look at the RPMs. I've managed to build something
> that resembles a 7.2 package, but there are a number of things that we
> should talk about so this ends up being useful.
>
> * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> installed whenever Tk support is configured (which is correct, IMO).
> Maybe this is just a legacy item?
For 7.1.3, it does make a difference....
%if %pgaccess# pgaccess installationpushd src/bininstall -m 755 pgaccess/pgaccess $RPM_BUILD_ROOT/usr/binmkdir -p
$RPM_BUILD_ROOT/usr/share/pgsql/pgaccessinstall-m 644 pgaccess/main.tcl $RPM_BUILD_ROOT/usr/share/pgsql/pgaccesstar cf
-pgaccess/lib pgaccess/images | tar xf - -C $RPM_BUILD_ROOT/usr/share/pgsqlcp -a pgaccess/doc/html
../../doc/pgaccesscp pgaccess/demo/*.sql ../../doc/pgaccesspopd
%endif
(in addition to the actual package). The 7.2 build procedure might
differ. It's still useful to have several packages, as it under some
circumstances it would be useful to have tk bindings but not ship
pgaccess. E.g. if you were to ship an Asian version, this segregation
might be useful.
>
> * I removed the {plperl} parameter, because PL/Perl now builds by default
> on Linux. Should plperl continue to stay its own package? I'd say yes,
> because you don't need in on every client.
Not only that, but you very often don't want to build it. If you have
a static perl package, plperl can't be created. It will sort of work
on IA32, but bomb out elsewhere. Ideally, the configure process should
figure out this on it's own (you can't create dynamic extensions
linking in a static lib).
> * Related to previous, the tcl package currently includes client and
> server components. I'd say this is more useful as two separate packages.
It might, if you imply that tcl is useful at all ;).
> * Similar issues with PL/Python
Same issues wrt. static libraries as for perl, but could easily be
separated.
> * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is
> in -tcl? What about libpgtcl.h? Currently, the -devel package has an
> implicit dependency on Tcl, which should probably not be there.
>
> * How long do we want to keep the libpq.so.2.0 symlink?
A long time :)
> * I fail to understand the motivation behind the way the -contrib package
> is done. You seem to be installing the source code. I scrapped that and
> installed the binaries the way it was designed to be.
Often the only source of docs, but I wouldn't miss it. I've often
wanted to kill this inconsistency myself.
> * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> that conveys a semantic difference from pg_dump. Possibly, these files
> should not be installed into /usr/bin if they're not general
> purpose.
They are programs serving specific dumping purposes.
> * What about the JDBC driver? I think the driver should be compiled in
> place by whatever JDK the build system provides.
Many build systems don't have a JDK, as there are no open (or even
distributable) JDKs.
> * Start thinking about how to package National Language Support.
Look at the find_lang macro.
> * Lot's of dependencies failing to be declared.
For the finished packages, those are generated automatically. As for
build dependencies, I'm unaware of any missing ones.
--
Trond Eivind Glomsrød
Red Hat, Inc.
On Sunday 16 September 2001 11:22 pm, Peter Eisentraut wrote:
> I just took a dreadful look at the RPMs. I've managed to build something
> that resembles a 7.2 package, but there are a number of things that we
> should talk about so this ends up being useful.
First, thanks for taking a look. However,I don't think 'dreadful' is a
really appropriate word here. But I'll let it slide. RPM packaging in
general can be a dreadful experience -- and that's what I'm going to assume
that you meant.
And, while your list is a usable list of things, the lack of addressing any
of these items in no way prevents a package of 7.2 from being 'useful' for
various degrees of usefulness.
> * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> installed whenever Tk support is configured (which is correct, IMO).
> Maybe this is just a legacy item?
As I've not yet had the time to build any 7.2 RPMsets, I'll have to look. It
may very well be legacy if 7.2's makefiles do such a decision as to install
pgaccess and where to install it.
But, pgaccess!=tk_client_support and might not even be desired by a tk client
user.
> * I removed the {plperl} parameter, because PL/Perl now builds by default
> on Linux. Should plperl continue to stay its own package? I'd say yes,
> because you don't need in on every client.
PL/perl requires a dynamic load libperl.so -- which Red Hat doesn't ship. If
configure can test for a dynamic libperl (which is being done in the makefile
as of 7.1.3), then that's where that decision ought to be made. However,
Karl DeBisschop can shed much light on this particular subject, and his
opinion should be weighed, as he knowsof some interesting situations.
As to it remaining a separate package -- absolutely. PL/perl is a
server-side package, while the perl client might be installed without a
server on its system. Don't want to force the server on a perl client
machine.
> * Related to previous, the tcl package currently includes client and
> server components. I'd say this is more useful as two separate packages.
> * Similar issues with PL/Python
I agree, and had planned on doing just this.
> * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is
> in -tcl? What about libpgtcl.h? Currently, the -devel package has an
> implicit dependency on Tcl, which should probably not be there.
Huh? The libs package is intended to be the base client libraries that all
clients need. The tcl library is only needed by the tcl client. The
libpgtcl.a static lib is only needed in development, and doesn't depend upon
tcl directly. Although I have yet to see a RedHat system without tcl
installed.... The tcl package could, I guess, inherit libpgtcl.a from the
_devel_ package (libpgtcl.a lives there, not in libs) without problems.
> * How long do we want to keep the libpq.so.2.0 symlink?
Good question. Trond's answer is a 'long time' -- When is the next major
uprev in the library going to be? This needs to be researched -- the
question that needs answering here is 'how many third-party packages (such as
the php postgresql interface; the DBI postgresql interface, etc) are going to
be broken by this?'
> * I fail to understand the motivation behind the way the -contrib package
> is done. You seem to be installing the source code. I scrapped that and
> installed the binaries the way it was designed to be.
Contrib, to my eyes, is both an example set as well as useful stuff. As 7.1
was the first setof RPM's with contrib compiled at all (previously, the
entire contrib tree was packaged as source code for documentation!), having
the source as well enables examples -- however, I understand both sides of
that.
However, I'm concerned about your wording 'the way it was designed to be' --
would you mind explaining exactly what you meant (a copy of your spec file
will explain far better than any narrative could, BTW)?
> * The -docs package is misleading. Maybe it should be called -docs-devel
> or something. However, I'm having a hard time understanding how people
> can make use of this.
'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML
editor/publishing system to generate various docs formats? It was previously
packaged as part of the main package and I split it out.
> * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> that conveys a semantic difference from pg_dump. Possibly, these files
> should not be installed into /usr/bin if they're not general purpose.
Hmmm. Any suggestions as to location and name? Might I suggest
'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too
inflammatory? :-) However, I tend to agree -- /usr/bin might not be the best
location for these scripts.
> * What about the JDBC driver? I think the driver should be compiled in
> place by whatever JDK the build system provides.
Got an open source JDK suggestion? One that is _standard_ for the target
distributions?
> * Start thinking about how to package National Language Support.
Explain what you mean by this.
> * Lot's of dependencies failing to be declared.
Most dependencies are automatic and do not need declaration. Can you give a
list of undeclared dependencies that are not auto generated during the build
that are not part of a standard development system for building, and part of
a standard installation for run-time?
> There are also a number of plain bug fixes that need to be integrated.
Ok. List, please?
A copy of your initial spec file and patchset would also be useful.
Once again, thanks for the look-through. You previous look-throughs wevery
useful, and I appreciate them. And I'll go ahead and apologize if my
comments seem to be short and maybe even grumpy -- I just got done with an 80
hour week involving a 25 kilowatt AM broadcast transmitter installation, so
I'm not at my best at the moment -- but I'm not intending to be short or
grumpy (although my wife might disagree.... :-)).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Trond Eivind Glomsrød writes:
> > * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> > installed whenever Tk support is configured (which is correct, IMO).
> > Maybe this is just a legacy item?
>
> For 7.1.3, it does make a difference....
>
> %if %pgaccess
[...]
> %endif
>
> (in addition to the actual package). The 7.2 build procedure might
> differ. It's still useful to have several packages, as it under some
> circumstances it would be useful to have tk bindings but not ship
> pgaccess. E.g. if you were to ship an Asian version, this segregation
> might be useful.
Given that pgtksh is rather small in size I don't know if that's worth the
contortions. However, note that pgaccess is still built if you turn on Tk
but turn off %pgaccess. (There was also a plan to make pgaccess use
pgtksh, but it's not happening for 7.2.)
> Not only that, but you very often don't want to build it. If you have
> a static perl package, plperl can't be created. It will sort of work
> on IA32, but bomb out elsewhere. Ideally, the configure process should
> figure out this on it's own (you can't create dynamic extensions
> linking in a static lib).
There are provisions in the source for figuring this out automatically.
Currently, the only "figuring" it does is to allow it on Linux. (It is my
understanding that it works on Linux independent of the CPU architecture.
In the past there have been problems with insufficient dynamic loader
implementations, but there is no principal design obstacle.)
But it would really be of advantage if distributors (i.e., you) supplied a
shared libperl by default. There are at least two high profile users
(PostgreSQL and Apache) running into this problem.
> > * I request that rh-pgdump.sh and postgresql-dump be renamed to something
> > that conveys a semantic difference from pg_dump. Possibly, these files
> > should not be installed into /usr/bin if they're not general
> > purpose.
>
> They are programs serving specific dumping purposes.
Maybe they should be named to reflect these purposes? Currently,
postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
conveys the meaning of "Red Hat's (better/different) pg_dump".
> > * What about the JDBC driver? I think the driver should be compiled in
> > place by whatever JDK the build system provides.
>
> Many build systems don't have a JDK, as there are no open (or even
> distributable) JDKs.
From Red Hat I would have expected the answer "use gcj". ;-) (I don't
know how complete the class library is there, and Ant probably doesn't
support it anyway.) However, two questions arise:
* If the build system doesn't have a JDK, why do you need a JDBC driver?
* There is currently no "official" source of PostgreSQL JDBC driver
binaries. So I don't know how you plan to obtain a precompiled jar
without making it yourself.
Well, do you have time to work on this and do you keep the RPM input files
under version control somewhere, so I can send some incremental patches?
The preliminary spec file patch is already the same size as the spec file.
:-/
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
> Trond Eivind Glomsrød writes:
>
> > > * The {pgaccess} parameter doesn't do anything AFAICT. PgAccess is
> > > installed whenever Tk support is configured (which is correct, IMO).
> > > Maybe this is just a legacy item?
> >
> > For 7.1.3, it does make a difference....
> >
> > %if %pgaccess
> [...]
> > %endif
> >
> > (in addition to the actual package). The 7.2 build procedure might
> > differ. It's still useful to have several packages, as it under some
> > circumstances it would be useful to have tk bindings but not ship
> > pgaccess. E.g. if you were to ship an Asian version, this segregation
> > might be useful.
>
> Given that pgtksh is rather small in size I don't know if that's worth the
> contortions. However, note that pgaccess is still built if you turn on Tk
> but turn off %pgaccess. (There was also a plan to make pgaccess use
> pgtksh, but it's not happening for 7.2.)
It may be built, but at least you don't get the package... Personally,
I wouldn't mind separating the database core from all the other things
bundled with it (drivers, support programs). It seems a little cleaner.
> > Not only that, but you very often don't want to build it. If you have
> > a static perl package, plperl can't be created. It will sort of work
> > on IA32, but bomb out elsewhere. Ideally, the configure process should
> > figure out this on it's own (you can't create dynamic extensions
> > linking in a static lib).
>
> There are provisions in the source for figuring this out automatically.
> Currently, the only "figuring" it does is to allow it on Linux. (It is my
> understanding that it works on Linux independent of the CPU architecture.
> In the past there have been problems with insufficient dynamic loader
> implementations, but there is no principal design obstacle.)
No. It works on IA32, but breaks elsewhere.
> But it would really be of advantage if distributors (i.e., you) supplied a
> shared libperl by default. There are at least two high profile users
> (PostgreSQL and Apache) running into this problem.
It's not unlikely to happen for the next major series (we try hard to
stay binary compatible within a series).
> Maybe they should be named to reflect these purposes? Currently,
> postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh
> conveys the meaning of "Red Hat's (better/different) pg_dump".
It was basically "doh, the existing dump script is very broken and we
freeze very soon" a release or two ago. I think Lamar was the one who
discoverd it and I the one who wrote it rather quickly.
> > > * What about the JDBC driver? I think the driver should be compiled in
> > > place by whatever JDK the build system provides.
> >
> > Many build systems don't have a JDK, as there are no open (or even
> > distributable) JDKs.
>
> From Red Hat I would have expected the answer "use gcj". ;-) (I don't
> know how complete the class library is there, and Ant probably doesn't
> support it anyway.) However, two questions arise:
gcj is nice, but far from complete. It's also Java 1.1 without AWT,
AFAIR, and most interesting stuff use 1.2 and up now.
> * If the build system doesn't have a JDK, why do you need a JDBC
> driver?
That you can use with gcj :). The main reason it's useful is that
other can install their own JDK, typically when running servlets or
other server based Java apps.
> Well, do you have time to work on this and do you keep the RPM input files
> under version control somewhere, so I can send some incremental
> patches?
If you send it, I can have a first look. As for time, that's something
other people have. And when I have it, I don't have anything to use it
for either (maxed out with 5 weeks unused vacation now, but have no
idea what to use most of it for)
--
Trond Eivind Glomsrød
Red Hat, Inc.
On Monday 17 September 2001 02:21 pm, Peter Eisentraut wrote: > Trond Eivind Glomsrød writes: >> > Given that pgtksh is rather small in size I don't know if that's worth the > contortions. However, note that pgaccess is still built if you turn on Tk > but turn off %pgaccess. (There was also a plan to make pgaccess use > pgtksh, but it's not happening for 7.2.) Built!=shipped in the RPMset. Lots of things are built -- but if it's not in the %files list, it don't get packaged. > Maybe they should be named to reflect these purposes? Currently, > postgresql-dump is just another spelling of pg_dump, and rh-pgdump.sh > conveys the meaning of "Red Hat's (better/different) pg_dump". I've already suggested a name that fits the purpose. > * If the build system doesn't have a JDK, why do you need a JDBC driver? To use a compiled bytecode java application built against our JDBC with a JRE? > * There is currently no "official" source of PostgreSQL JDBC driver > binaries. So I don't know how you plan to obtain a precompiled jar > without making it yourself. Yes, we would have to build it now. However, the question still looms: _which_ JDK should be used to build it for maximum JVM/JRE compatibility for the bytecode distribution? I've asked this question before, and no consensus was reached. > Well, do you have time to work on this and do you keep the RPM input files > under version control somewhere, so I can send some incremental patches? I will have time shortly. It has been discussed in the past on two separate occassions about putting the spec file into CVS at postgresql.org, but, again, no consensus was reached and no action was taken by core to implement that. If I had to I could set up my own CVS repository -- but I haven't needed to as yet. Send a patch to me and Trond against the last PGDG release specfile. If you change the patchset, it needs to be included, as well as patches to any scripts distributed. > The preliminary spec file patch is already the same size as the spec file. ??? That's pretty big. E-mail me and Trond your changes, please. We're getting ready to go into beta, and I was getting ready to ramp up to deal with 7.2beta RPMs anyway. This just quickens the issue. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Monday 17 September 2001 05:44 pm, Peter Eisentraut wrote: > ...useful in the sense that the work I'm doing becomes useful. Ok. My mind is a little muddy right now, and different interpretations of wordings aren't coming easily. > The other thing is that no matter how you arrange it, libpgtcl.a and > libpgtcl.so should be in the same package. I placed them in -devel for > now since that is what you seemed to be intending anyway. Yes, that is and was my intentions; I just missed the significance of what you said. Of course, the .so and the .a need to be together in this instance (like the libpq.so/libpq.a instance as well, which was addressed earlier in the 7.1.x RPMset cycle). > > Contrib, to my eyes, is both an example set as well as useful stuff. > That used to be sort of true. Currently, contrib is more "useful stuff" > than example. Examples are in the documentation and the tutorial > directory. Then the change is valid. > > However, I'm concerned about your wording 'the way it was designed to be' > > -- would you mind explaining exactly what you meant (a copy of your spec > > file will explain far better than any narrative could, BTW)? > I mean contrib is intended to be compiled, installed, and used. Ok. I was more talking about location in the filesystem, but I get your point. > > 'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML > > editor/publishing system to generate various docs formats? > Difficult without having a real source tree available. Hmmm. I've not tried to do anything with the SGML yet.... > > Hmmm. Any suggestions as to location and name? Might I suggest > > 'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too > > inflammatory? :-) > No, but it's longer than the 14 characters that POSIX allows for file > names. ;-) But "upgrade" is a reasonable start. But we already had a pg_upgrade in the tarball. 'pg_migrate' perhaps? And it _is_ a kludge. > > > * What about the JDBC driver? I think the driver should be compiled in > > > place by whatever JDK the build system provides. > > > > Got an open source JDK suggestion? One that is _standard_ for the target > > distributions? > There is no standard C compiler in the target distributions either... Gcc is the de facto linux distribution standard, and one can reasonably assume that a standard C compiler is present. The same is not true of JDK's, AFAIK. > Note that the choice of JDK is actually hidden from the build process. > You just need Ant, which comes in RPM form. Hmmm. How does one get started with 'Ant' and a JDK? I personally don't use Java -- but heretofore it's been easy to get jars of the JDBC to package for people who do use Java. Is a JDBC RPM package something people are actively using? I _have_ received a few questions from people trying to use the JDBC RPM, so I think it is a useful thing to have. Somebody who knows Java: enlighten me on the portability or lack thereof of our distributed JDBC RPM's jar, please. If I can build a reasonably portable jar of our JDBC,I'm willing to try. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Trond Eivind Glomsrød writes: > > There are provisions in the source for figuring this out automatically. > > Currently, the only "figuring" it does is to allow it on Linux. (It is my > > understanding that it works on Linux independent of the CPU architecture. > > In the past there have been problems with insufficient dynamic loader > > implementations, but there is no principal design obstacle.) > > No. It works on IA32, but breaks elsewhere. Libtool seems to think otherwise. And the people who provided the patches to libtool are the ones who should know best. > > But it would really be of advantage if distributors (i.e., you) supplied a > > shared libperl by default. There are at least two high profile users > > (PostgreSQL and Apache) running into this problem. > > It's not unlikely to happen for the next major series (we try hard to > stay binary compatible within a series). You don't break binary compatibility by providing a shared library alongside a static one. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes: > Trond Eivind Glomsrød writes: > > > > There are provisions in the source for figuring this out automatically. > > > Currently, the only "figuring" it does is to allow it on Linux. (It is my > > > understanding that it works on Linux independent of the CPU architecture. > > > In the past there have been problems with insufficient dynamic loader > > > implementations, but there is no principal design obstacle.) > > > > No. It works on IA32, but breaks elsewhere. > > Libtool seems to think otherwise. And the people who provided the > patches to libtool are the ones who should know best. Dynamic code works on those platforms. What doesn't work is dlopen() of code not compiled with -fpic (which means extensions linking with static libraries). I've not seen libtool claim otherwise, but it would be broken. Another can of worms is nsswitch inside glibc, which in some circumstances will use a dynamic module in a statically linked program. > > > But it would really be of advantage if distributors (i.e., you) supplied a > > > shared libperl by default. There are at least two high profile users > > > (PostgreSQL and Apache) running into this problem. > > > > It's not unlikely to happen for the next major series (we try hard to > > stay binary compatible within a series). > > You don't break binary compatibility by providing a shared library > alongside a static one. This mean backward as well... eg. perl packages for RHL 7.1 should run on RHL 7 as well. Same for RHL 7.2, if we make such a release. -- Trond Eivind Glomsrød Red Hat, Inc.
On Monday 17 September 2001 05:40 pm, Trond Eivind Glomsrød wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > You don't break binary compatibility by providing a shared library > > alongside a static one. > This mean backward as well... eg. perl packages for RHL 7.1 should run > on RHL 7 as well. Same for RHL 7.2, if we make such a release. Distributors' needs are very different from our needs, Peter. Maybe a potential Red Hat 8 can do such. However, the backwards compatibilty issue is some rub. Our PGDG packages, OTOH, don't have to be limited in that way. Which is one reason you may want to start there, not the Red H?at package (which is close, but not identical, to ours). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > And, while your list is a usable list of things, the lack of addressing any > of these items in no way prevents a package of 7.2 from being 'useful' for > various degrees of usefulness. ...useful in the sense that the work I'm doing becomes useful. > > * Is libpgtcl.a supposed to be in the -libs package, while libpgtcl.so is > > in -tcl? What about libpgtcl.h? Currently, the -devel package has an > > implicit dependency on Tcl, which should probably not be there. > > Huh? The libs package is intended to be the base client libraries that all > clients need. The tcl library is only needed by the tcl client. The > libpgtcl.a static lib is only needed in development, and doesn't depend upon > tcl directly. Although I have yet to see a RedHat system without tcl > installed.... The tcl package could, I guess, inherit libpgtcl.a from the > _devel_ package (libpgtcl.a lives there, not in libs) without problems. My interpretation of dependency is "this file cannot be made use of unless that package is installed". Hence, libpgtcl.h and libpgtcl.a have a dependency on the tcl package and therefore the postgresql-devel package has that same dependency. That is one thing, and other interpretations may be valid. The other thing is that no matter how you arrange it, libpgtcl.a and libpgtcl.so should be in the same package. I placed them in -devel for now since that is what you seemed to be intending anyway. > > * How long do we want to keep the libpq.so.2.0 symlink? > > Good question. Trond's answer is a 'long time' -- When is the next major > uprev in the library going to be? "Never" is my best guess. > Contrib, to my eyes, is both an example set as well as useful stuff. That used to be sort of true. Currently, contrib is more "useful stuff" than example. Examples are in the documentation and the tutorial directory. > However, I'm concerned about your wording 'the way it was designed to be' -- > would you mind explaining exactly what you meant (a copy of your spec file > will explain far better than any narrative could, BTW)? I mean contrib is intended to be compiled, installed, and used. > 'docs-sgml' perhaps? Maybe they want to try their hand at using an SGML > editor/publishing system to generate various docs formats? Difficult without having a real source tree available. Plus, people that want to work on documentation also have the option of getting the postgresql-docs-xxx.tar.gz source package that contains the documentation sources. > Hmmm. Any suggestions as to location and name? Might I suggest > 'kludge-to-get-around-postgresql-lack-of-upgradability' -- or is that too > inflammatory? :-) No, but it's longer than the 14 characters that POSIX allows for file names. ;-) But "upgrade" is a reasonable start. > > * What about the JDBC driver? I think the driver should be compiled in > > place by whatever JDK the build system provides. > > Got an open source JDK suggestion? One that is _standard_ for the target > distributions? There is no standard C compiler in the target distributions either... You don't need a standard JDK either. You want to build the driver to fit the JDK that the distribution provides. If the distribution doesn't provide Java support, you don't need a JDBC driver. Note that the choice of JDK is actually hidden from the build process. You just need Ant, which comes in RPM form. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter