Re: 7.2 RPMs - Mailing list pgsql-hackers

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