Re: 7.2 RPMs

Peter Eisentraut <peter_e(at)gmx(dot)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 installation
pushd src/bin
install -m 755 pgaccess/pgaccess $RPM_BUILD_ROOT/usr/bin
mkdir -p $RPM_BUILD_ROOT/usr/share/pgsql/pgaccess
install -m 644 pgaccess/main.tcl $RPM_BUILD_ROOT/usr/share/pgsql/pgaccess
tar cf - pgaccess/lib pgaccess/images | tar xf - -C $RPM_BUILD_ROOT/usr/share/pgsql
cp -a pgaccess/doc/html ../../doc/pgaccess
cp pgaccess/demo/*.sql ../../doc/pgaccess
popd
%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.