bugGNU Octave - Bugs: bug #38491, PKG_ADD fails with __all_db_opts__...

 
 

bug #38491: PKG_ADD fails with __all_db_opts__ undefined

Submitter:  None
Submitted:  Sat 09 Mar 2013 02:50:15 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Clemens Buchacher Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.3
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 17 Mar 2013 07:10:00 PM UTC, comment #10: 

Configuration of postgresql include directories should be fixed now, too (in SVN).

Olaf Till <i7tiol>
Group Member
Sun 17 Mar 2013 12:12:50 PM UTC, comment #9: 

database in SVN is now changed to work around the path problem with 'pkg build'.

The cause of the problem is probably elsewhere; I'll care about whether an extra bug-report is necessary.

Don't close this report until I've fixed the configuration issue also.

Olaf

Olaf Till <i7tiol>
Group Member
Sat 16 Mar 2013 07:54:17 PM UTC, comment #8: 

I paste the reply from Clemens below, since it does not seem to have reached the tracker.

Thanks for the information. The situation is indeed similar to Fedora.

Of course it's no mistake to report the 'pkg build' issue here as long as the situation is not clear. Since you think it's more urgent, I'll look into the pkg issue first (but probably not today). As for a workaround, however, this could be to 'pkg install' the package first, so that the function will be in the path.


------- From: Clemens Buchacher <drizzd@aon.at> -------

Here's where the files are located on Arch. Note that some files exist
twice (even if they did not in Olaf's list).

While I do appreciate a solution for the include files, that was
actually pretty easy to work around with a simple sed script. So I
mentioned it in the report mostly for completeness. The PKG_ADD problem
is not so easy to work around.

Note that f.e. the geometry package detects the pkg build phase in its
PKG_ADD. Maybe that could be used to work around the issue.

[local_packages, global_packages] = pkg("list");
installed_pkgs_lst = {local_packages{:}, global_packages{:}};
pkg_data = installed_pkgs_lst (cellfun(@(x) ismember (x.name, {"geometry"}), ...
                                             installed_pkgs_lst, "unif", true));
if isempty(pkg_data)
  % The package is not installed yet


If as you say, the PKG_ADD issue is a bug in pkg build, is it not also
correct for me to report it here?

Regards,
Clemens
---

postgresql      /usr/include/postgresql/server/mb/pg_wchar.h
postgresql-libs /usr/include/libpq-events.h
postgresql      /usr/include/postgresql/server/postgres.h
postgresql      /usr/include/postgresql/server/pg_config_os.h
postgresql-libs /usr/include/pg_config_os.h
postgresql-libs /usr/include/postgresql/internal/port.h
postgresql-libs /usr/include/postgresql/internal/postgres_fe.h
postgresql-libs /usr/include/postgresql/internal/c.h
postgresql-libs /usr/include/postgresql/internal/libpq/pqcomm.h
postgresql-libs /usr/include/postgresql/internal/libpq-int.h
postgresql-libs /usr/include/postgresql/internal/pqexpbuffer.h
postgresql      /usr/include/postgresql/server/port.h
postgresql      /usr/include/postgresql/server/utils/errcodes.h
postgresql      /usr/include/postgresql/server/utils/elog.h
postgresql      /usr/include/postgresql/server/utils/palloc.h
postgresql      /usr/include/postgresql/server/postgres_fe.h
postgresql      /usr/include/postgresql/server/pg_config_manual.h
postgresql-libs /usr/include/pg_config_manual.h
postgresql      /usr/include/postgresql/server/c.h
postgresql      /usr/include/postgresql/server/pg_config.h
postgresql-libs /usr/include/pg_config.h
postgresql-libs /usr/include/libpq-fe.h
postgresql      /usr/include/postgresql/server/pg_trace.h
postgresql      /usr/include/postgresql/server/libpq/libpq-fs.h
postgresql-libs /usr/include/libpq/libpq-fs.h
postgresql      /usr/include/postgresql/server/postgres_ext.h
postgresql-libs /usr/include/postgres_ext.h
postgresql      /usr/include/postgresql/server/nodes/nodes.h
postgresql      /usr/include/postgresql/server/catalog/genbki.h
postgresql      /usr/include/postgresql/server/catalog/pg_type.h

Olaf Till <i7tiol>
Group Member
Sat 16 Mar 2013 04:13:29 PM UTC, comment #7: 

Thanks, Mike. A comparison with where non-packaged postgresql would put its headers to shows that Fedora adhers to this even better than my debian (except that the default 'postgresql' pkgincludedir is replaced by 'pgsql'). It looks sensible, and done this way my argument with the filename clashes does not apply. I guess it's similar in Arch Linux. So of course I have to rework configure a bit.

Olaf Till <i7tiol>
Group Member
Fri 15 Mar 2013 11:50:36 PM UTC, comment #6: 

I'm neither OP nor an Arch user :) But as another data point, here is a list of matching header files from the Fedora 18 postgresql-devel package:

/usr/include/pgsql/server/mb/pg_wchar.h
/usr/include/libpq-events.h
/usr/include/pgsql/server/postgres.h
/usr/include/pg_config_os.h
/usr/include/pgsql/server/pg_config_os.h
/usr/include/pgsql/internal/port.h
/usr/include/pgsql/internal/postgres_fe.h
/usr/include/pgsql/internal/c.h
/usr/include/pgsql/internal/libpq/pqcomm.h
/usr/include/pgsql/internal/libpq-int.h
/usr/include/pgsql/internal/pqexpbuffer.h
/usr/include/pgsql/internal/port.h
/usr/include/pgsql/server/port.h
/usr/include/pgsql/server/utils/errcodes.h
/usr/include/pgsql/server/utils/elog.h
/usr/include/pgsql/server/utils/palloc.h
/usr/include/pgsql/internal/postgres_fe.h
/usr/include/pgsql/server/postgres_fe.h
/usr/include/pg_config_manual.h
/usr/include/pgsql/server/pg_config_manual.h
/usr/include/pgsql/internal/c.h
/usr/include/pgsql/server/c.h
/usr/include/pg_config.h
/usr/include/pgsql/server/pg_config.h
/usr/include/libpq-fe.h
/usr/include/pgsql/server/pg_trace.h
/usr/include/libpq/libpq-fs.h
/usr/include/pgsql/server/libpq/libpq-fs.h
/usr/include/pgsql/server/postgres_ext.h
/usr/include/postgres_ext.h
/usr/include/pgsql/server/nodes/nodes.h
/usr/include/pgsql/server/catalog/genbki.h
/usr/include/pgsql/server/catalog/pg_type.h

It looks like -I/usr/include/pgsql/server has everything you listed, along with the default /usr/include of course.

Mike Miller <mtmiller>
Group Member
Fri 15 Mar 2013 10:39:05 PM UTC, comment #5: 

I agree, but only if it is a systematic feature of a system, not a bug that will eventually be corrected.

Ok, let's try to help finding out which of both is the case. As a first step, could the original reporter please tell the locations under the main include directory of these files (from my postgresql/ include subdirectory):

mb/pg_wchar.h
libpq-events.h
postgres.h
pg_config_os.h
internal/port.h
internal/postgres_fe.h
internal/c.h
internal/libpq/pqcomm.h
internal/libpq-int.h
internal/pqexpbuffer.h
port.h
utils/errcodes.h
utils/elog.h
utils/palloc.h
postgres_fe.h
pg_config_manual.h
c.h
pg_config.h
libpq-fe.h
pg_trace.h
libpq/libpq-fs.h
postgres_ext.h
nodes/nodes.h
catalog/genbki.h
catalog/pg_type.h

Olaf

Olaf Till <i7tiol>
Group Member
Fri 15 Mar 2013 10:01:33 PM UTC, comment #4: 


> but directly under postgresql/ (on my system).


You may think that arch is broken, but that's precisely what a configure script is for, for handling "broken" OSes.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Fri 15 Mar 2013 09:50:19 PM UTC, comment #3: 


> I disagree that this bug is invalid. If some OS has the
> postgres headers without the postgres/ prefix, that should be
> accounted for by the configure script.


The include directory postgresql/ and its subdirectories contain files with quite general names, which should not be in the main include directory due to danger of file name clashes. 'c.h', e.g., is also a name of a file provided by deb-package libsrecord-dev; 'port.h' is in many other packages. It would not be nice to rely on all other packages to keep their possibly name-clashing include files in extra directories so that postgresql needn't do it. Keeping the subdirectories of postgresql/ in the main include directory would also be no solution since these are partially also very generally named (e.g. 'utils'); and one of the two 'c.h' files of postgresql is not even in a subdirectory, but directly under postgresql/ (on my system).

So my thinking that it is just an error to keep postgesqls include files in the main include directory had reasons. Except if someone can tell me some reason that I can't see yet, I'd still think that it is not reasonable to try to configure for postgresql include files in the main include directory.

> Yeah, bugs are annoying, but we can't just dismiss bugs because
> they're annoying.


I don't think that bugs are annoying, and I don't dismiss bugs just because they are annoying.

Olaf Till <i7tiol>
Group Member
Fri 15 Mar 2013 02:01:12 PM UTC, comment #2: 

I disagree that this bug is invalid. If some OS has the postgres headers without the postgres/ prefix, that should be accounted for by the configure script.

Yeah, bugs are annoying, but we can't just dismiss bugs because they're annoying.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Fri 15 Mar 2013 11:08:45 AM UTC, comment #1: 

Thanks for the report, but the error is a bug in pkg.m, which probably should not run the PKG_ADD commands if called as 'pkg build ...'.

As for your architecture specificities, I'm not sure we should try to cope with them in the package. I'd think having the include files not under postgresql/ is just wrong.

As for your installation prefices of packages, these don't seem to be unusual.

Can someone with permissions please close this bug?

Olaf

Olaf Till <i7tiol>
Group Member
Sat 09 Mar 2013 02:50:15 PM UTC, original submission:  

Hi,

The attached octave.out file contains the output of the following command:

octave --eval "pkg build -verbose -nodeps builddir database-2.1.0.tar.gz"

It fails in PKG_ADD saying that _all_db_opts_ is undefined.

- In order to get this far I had to remove the postgresql/ prefixes because on my system (Arch Linux), the corresponding include files are installed directly in /usr/include.

- I have also changed the following line in configure.ac, but this appears to make no difference:

-AC_INIT([database], [2.0.0], [i7tiol@t-online.de])
+AC_INIT([database], [2.1.0], [i7tiol@t-online.de])

The Arch Linux setup is also unusual since it installs the architecture dependent files separately:

>> pkg prefix /usr/share/octave/packages /usr/lib/octave/packages


The command has no effect on pkg build, but pkg install succeeds:

sudo octave --eval "pkg prefix /usr/share/octave/packages /usr/lib/octave/packages; pkg install -verbose -nodeps database-2.1.0.tar.gz"

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #27585:  octave.out added by None (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by i7tiol (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-03-18 carandraug StatusNone Fixed
        Open/ClosedOpen Closed
    2013-03-09 None Attached File- Added octave.out, #27585

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code