[Buildroot] [PATCH v2] postgresql: new package
Peter Seiderer
ps.report at gmx.net
Sun Mar 30 23:34:03 UTC 2014
Hello Thomas,
> Gesendet: Montag, 31. März 2014 um 00:13 Uhr
> Von: "Thomas Petazzoni" <thomas.petazzoni at free-electrons.com>
> An: "Peter Seiderer" <ps.report at gmx.net>
> Cc: buildroot at busybox.net
> Betreff: *** GMX Spamverdacht *** Re: [Buildroot] [PATCH v2] postgresql: new package
>
> Dear Peter Seiderer,
>
> On Sun, 30 Mar 2014 23:54:01 +0200, Peter Seiderer wrote:
>
> > > regc_pg_locale.c: In function ‘pg_wc_tolower’:
> > > regc_pg_locale.c:658:12: error: dereferencing pointer to incomplete type
> > > regc_pg_locale.c:658:12: error: dereferencing pointer to incomplete type
> > > make[4]: *** [regcomp.o] Erreur 1
> > > make[4]: quittant le répertoire « /home/thomas/projets/buildroot/output/build/postgresql-9.3.3/src/backend/regex »
> > >
> >
> > o.k. I will take a look at it...
Stripped the problem down to this programm:
--- begin: test.c ---
#include <locale.h>
#include <ctype.h>
int f(int c, locale_t l) {
return isdigit_l(c, l);
}
--- end ---
With (x86_64 on OpenSuse) I get no problem:
gcc -Wall -D_GNU_SOURCE -c test.c
With the buildroot toolchain:
./host/usr/bin/arm-linux-gcc -Wall -D_GNU_SOURCE -c test.c
test.c: In function ‘f’:
test.c:5:9: error: dereferencing pointer to incomplete type
test.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
>
> Thanks!
>
> > > > +config BR2_PACKAGE_POSTGRESQL
> > > > + bool "PostgreSQL"
> > >
> > > should be lower-case.
> >
> > mhh, did take a look at package/mysql/Config.in: bool "MySQL" and did the same, use the
> > offical name which emphasises the SQL..., but I can change this if lower-case Menu entries
> > are an requirement?
>
> Yeah, MySQL has been around for a long time, but I have the impression
> that our policy is to use lower-case menu entries everywhere. I don't
> know how hard this rule is, though, so let's see if others share their
> opinion about this. This is clearly not a very important matter.
>
> > > Also, there are many, many more configuration options. You don't have
> > > to support all of them for a first submission, but if you don't support
> > > a given feature, you should pass --without-<foo> for it so that the
> > > configure script doesn't mistakenly detect a library from the host. So
> > > for example: --without-pam --without-python --without-perl, etc.
> > >
> > > I see that you're making readline and zlib mandatory dependencies, but
> > > they are not: the package has --without-readline and --without-zlib
> > > options. So instead of mandatory dependencies, you should use:
> > >
> > > ifeq ($(BR2_PACKAGE_READLINE),y)
> > > POSTGRESQL_CONF_OPT += --with-readline
> > > POSTGRESQL_DEPENDENDENCIES += readline
> > > else
> > > POSTGRESQL_CONF_OPT += --without-readline
> > > endif
> > >
> >
> > Did follow the PostgreSQL INSTALL hints stating:
> >
> > * The GNU Readline library is used by default. It allows psql (the
> > PostgreSQL command line SQL interpreter) to remember each command
> > you type, and allows you to use arrow keys to recall and edit
> > previous commands. This is very helpful and is strongly
> > recommended. If you don't want to use it then you must specify the
> > "--without-readline" option to "configure". As an alternative, you
> > can often use the BSD-licensed "libedit" library, originally
> > developed on NetBSD. The "libedit" library is GNU
> > Readline-compatible and is used if "libreadline" is not found, or
> > if "--with-libedit-preferred" is used as an option to "configure".
> > If you are using a package-based Linux distribution, be aware that
> > you need both the readline and readline-devel packages, if those
> >
> > and made the default enabled packages mandatory...
>
> I understand what the PostgreSQL guys say, but this statement is from
> the perspective of a developer who is using the command line pgsql
> tool. On an embedded system, except during development, there is not
> really a need to use pgsql interactively. And even during development,
> you can connect to the embedded PostgreSQL server using a remotely
> executed pgsql binary.
>
> So I would make the dependency optional, and then in the main Config.in
> option, in the help text, add something like:
>
> Enable the readline package to gain readline support in
> pgsql, which offers a much nicer user experience.
o.k. will do...
>
> > The same for zlib:
> >
> > * The zlib compression library is used by default. If you don't want
> > to use it then you must specify the "--without-zlib" option to
> > "configure". Using this option disables support for compressed
> > archives in pg_dump and pg_restore.
> >
> > But I can make readline/zlib optional (with some comment in the
> > Config.in file)?
>
> Yes, that would be nice I believe.
>
> > All other features/packages are optional (and disabled as the INSTALL file
> > states):
> >
> > The following packages are optional. They are not required in the
> > default configuration, but they are needed when certain build options
> > are enabled, as explained below:
> >
> > So I think there is no need to disable them explicitly?
>
> See what I explained in my previous reply:
>
> """
> You don't have to support all of them for a first submission, but if
> you don't support a given feature, you should pass --without-<foo> for
> it so that the configure script doesn't mistakenly detect a library
> from the host.
> """
>
> Or none of these options are auto-detected, and it's only if a
> --with-<something> or --enable-<something> option is passed that the
> configure script starts looking around to see if the necessary
> dependencies are available or not?
>
o.k, all of these options have no autodetectino (when I read the statements
in configure.in right)...
> > > > +define POSTGRESQL_USERS
> > > > + postgres -1 postgres -1 * /srv/pgsql/data /bin/sh postgres PostgreSQL Server
> > > > +endef
> > >
> > > Is /srv a normal location for databases? Isn't /var used in general?
> >
> > o.k, will change...
>
> This really was a question. I have no idea what we prefer to use in
> Buildroot. For example, have you looked where our mysql package puts
> its database stuff?
Your where right with the question, the Linux standard for this is
under /var/lib as given in the LinuxStandardBase/FilesystemHierarchyStandard ([1]):
var/lib: State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc.
[1] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Peter
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
More information about the buildroot
mailing list