Bug 578024

Created attachment 403406 [details]
Output from rpmlint

Generated on FC11 from: rpmlint srpm/ingres.spec /devsrc/rpmbuild/SRPMS/ingres-10.0.0-1.20100329svn2734.fc11.src.rpm /devsrc/rpmbuild/RPMS/i586/ingres-{client,server,devel,documentation,debuginfo}-10.0.0-1.20100329svn2734.fc11.i586.rpm

Well,

since it's a large beast, I would really appreciate help for a review.

Ingres builds fine under F-12 and mock

rpmlint ingres.spec
ingres.spec: W: invalid-url Source0: ingres-10.0.0-20100329svn2734.tgz
0 packages and 1 specfiles checked; 0 errors, 1 warnings.


rpmlint over compiled binaries produces:
5 packages and 0 specfiles checked; 102 errors, 600 warnings.

Warnings are mostly non-standard-gid/uid

More interesting
ingres-client.i686: E: non-standard-dir-perm /var/lib/ingres/files/name 0700
ingres-client.i686: E: setuid-binary /usr/libexec/ingres/bin/ingvalidpam root 04
511
ingres-client.i686: E: non-standard-executable-perm /usr/libexec/ingres/bin/ingv
alidpam 04511
ingres-client.i686: E: non-standard-executable-perm /usr/libexec/ingres/bin/ingv
alidpam 04511

* logrotate script is missing

* why do you start ingres-server in ingres-client package? IMHO, that's not necessary.

* ingres-server.i686: W: non-conffile-in-etc /etc/ld.so.conf.d/ingres-i386.conf

I would mark it as conf-file and remove arch from file-name
%config /etc/ld.so.conf.d/ingres.conf
same for pam-message in ingres-client

I forgot to mention, even if I could do a review, you'll still need a sponsor.

Hi Matthias,

Thanks for starting the review, your help is very much appreciated.

In response to your rpmlint comments:

ingres-client.i686: E: non-standard-dir-perm /var/lib/ingres/files/name 0700
This is the directory used by the Ingres name server which manages the port IDs of all the other server. For security reason, this dir must only be browseable by the ingres user
 
ingres-client.i686: E: setuid-binary /usr/libexec/ingres/bin/ingvalidpam root
04511
This module does the authentication for incoming remove connections and needs to read /etc/passwd, hence it's set uid root. (Which I believe is allowed here: http://fedoraproject.org/wiki/Privilege_escalation_policy)

Log rotate I need to do some research on apparently

I don't start ingres-server from the ingres-client package but I do stop it. Although it sounds counter intuitive, the ingres-client components also contain servers. The client and server components use the same mechanisms to start and stop and cannot really be controlled independently if both are installed. Generally speak Ingres is stopped and started as a product independent of which components are actually installed. If you need more details about this I'm happy to expand further.

Will update the ldconfing and pam config files as suggested.

I should note here that I've also realized I've not included most of the directories in the packaging. I have an update to resolve this and will include it with the ones mentioned above.

Jay,

sadly, I'm currently nearly out ouf time. I'll take a deeper look in the near future.

Matthias

A program that can only build on i686 may be not suitable for inclusion in fedora.

It does build on more architectures than i686. x86_64 & ia64 both build and are supported (ppc too, although it may require a little porting work). Just not from the current iteration of the packaging.
My thinking was that I wanted to get i686 working in an acceptable manor first of all and then worry about the other platforms. The x86_64 build, has 32bit runtime components to it which present another level of complexity for packaging. 

As this is my first attempt at packaging a product from source, I was expecting it to be very much an iterative process. I'm more than prepared to do the work necessary to get it included with Fedora.

As well as aspiring to be the packager for Ingres on Fedora, I'm also an upstream contributor. I've worked for the company for many years and one of my roles is the Linux build and packaging monkey. Whilst my primary goal is to get Ingres included in Fedora, I would also like to become more generally involved with the Fedora project.

Ingres is a mature, sophisticated and widely used product with substantial engineering resources behind it and I think its inclusion would benefit both the Ingres and Fedora communities.

(In reply to comment #7)
> It does build on more architectures than i686. x86_64 & ia64 both build and are
> supported (ppc too, although it may require a little porting work). Just not
> from the current iteration of the packaging.
> My thinking was that I wanted to get i686 working in an acceptable manor first
> of all and then worry about the other platforms. The x86_64 build, has 32bit
> runtime components to it which present another level of complexity for
> packaging. 
> 
At least, it should be built on x86_64 with 64bit runtimes.
See http://fedoraproject.org/wiki/Architectures

Just tried to install ingres packages. Hmm :-/

I suggest a renaming of binaries, or marking a conflict. (Mark a conflict with postgresql)



Transaction Check Error:
  file /usr/bin/isql from install of ingres-client-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from package unixODBC-2.2.14-9.fc12.i686
  file /usr/bin/createdb from install of ingres-server-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from package postgresql-8.4.3-1.fc12.i686
  file /usr/bin/report from install of ingres-client-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from package report-0.10-5.fc12.i686


[mrunge@mrungexp media]$ yum info report
Name       : report
Arch       : i686
Version    : 0.10
Release    : 5.fc12
Size       : 108 k
Repo       : installed
From repo  : updates
Summary    : Incident reporting library
URL        : http://fedorahosted.org/report
License    : GPLv2+
Description: A generic problem/bug/incident/error reporting library, that can be
           : configured to deliver a report to a variety of different ticketing
           : systems.

setroubleshoot requires report. Is it possible to rename report fron ingres-client?

(In reply to comment #9)
>   file /usr/bin/isql from install of
> ingres-client-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from
> package unixODBC-2.2.14-9.fc12.i686
>   file /usr/bin/createdb from install of
> ingres-server-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from
> package postgresql-8.4.3-1.fc12.i686
Will rename both of these

>   file /usr/bin/report from install of
> ingres-client-10.0.0-1.20100329svn2734.fc12.i686 conflicts with file from
> package report-0.10-5.fc12.i686
Will move this to /usr/libexec/ingres/bin, it's used to run reports written in Ingres report writer and is unlikely to be useful the average user any more.

(In reply to comment #8)
> (In reply to comment #7)
> > It does build on more architectures than i686. x86_64 & ia64 both build and are
> > supported (ppc too, although it may require a little porting work). Just not
> > from the current iteration of the packaging.
> > My thinking was that I wanted to get i686 working in an acceptable manor first
> > of all and then worry about the other platforms. The x86_64 build, has 32bit
> > runtime components to it which present another level of complexity for
> > packaging. 
> > 
> At least, it should be built on x86_64 with 64bit runtimes.
> See http://fedoraproject.org/wiki/Architectures    
The packaging guidelines say "least one of the primary architectures", but I should be able to get a 64bit only x86_64 build working too, fairly easily. As I said, building on the other platform was always my intention eventually.

Update: Not sleeping on this, just waiting for changes to get into upstream before posting...

Created attachment 412380 [details]
Output from rpmlint - 3.20100505svn2946

Apologies for the delay, new SPEC and SRPM available here:

ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres.spec
ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres-10.0.0-3.20100505svn2946.fc11.src.rpm

%changelog
* Thu May 04 2010 Jay Hankinson <jeremy.hankinson> 10.0.0-3
- Update source to svn r2946
- Add support for pure 64bit x86_64 builds
* Wed Apr 28 2010 Jay Hankinson <jeremy.hankinson> 10.0.0-2
- Use SVN revision for build number
- Add default database locations to dbms package
- Move /usr/bin/createdb to /usr/libexec/ingres/bin and add /usr/bin/ingcreatedb
- Move /usr/bin/report and /usr/bin/isql to /usr/libexec/ingres/bin
- Remove executable stack flag from libcompat.10.0.0.so
- Mark files in _sysconfdir as config
- Generate dir lists and add to file lists for each package

rpmlint output attached.

Some easy fix issues:
1.Those lines should be removed from spec
# Requries changes from upstream but can be supported
ExcludeArch:    ia64
# Not officially supported by upstream, but possible with some tweaking
ExcludeArch:    ppc
# As ppc
ExcludeArch:    ppc64
# Unsupported by upstream (although was previously)
ExcludeArch:    S390
# Unsupported by upstream
ExcludeArch:    ARM
# Unsupported by upstream
ExcludeArch:    Parisc
# Unsupported by upstream
ExcludeArch:    SPARC
Requires:       %{_bindir}/sed
Requires:       %{_bindir}/grep
Requires:       /sbin/runuser
Requires:       %{__tar}
Requires:       %{_bindir}/ipcs
Requires:       %{__awk}
2. Add those lines before %prep
%package client
Conflicts: ingres
Summary: Local and remote connectivity servers and utilities

%package server
Requires: %{name}-client = %{version}-%{release}
Summary: DBMS server and utilities

%package devel
Requires: %{name}-client = %{version}-%{release}
Summary: Application development

%package documentation
Summary: Documentation

%description client
Client side runtime and networking components and drivers
ODBC and JDBC drivers

%description server
DBMS server and database utilities

%description devel
Embedded SQL precompilers, headers and appliaction development tools

%description documentation
Full documentation set in PDF format

3.simply use cat and sed instead of %{__cat}  and %{__sed} 

4.%defattr(-,ingres,ingres,-) should always be %defattr(-,root,root,-)

5.%post devel
/sbin/ldconfig %{_libdir}/ingres seems not right
If the shlibs are in the subdirs of %{_lib}, you should add a file to /etc/ld.so.conf.d

6. Some SPEC references may be useful for you.
http://cvs.fedoraproject.org/viewvc/rpms/mysql/devel/
http://cvs.fedoraproject.org/viewvc/rpms/postgresql/devel/

1.%package documentation should be %package doc and should noarch.
2. Conflicts: ingres 
When possible, rpm should be avoid of using conficts
3.List files explicit rather than %file -f

(In reply to comment #15)
Apologies for the radio silence, I got pulled onto another project for a couple of weeks. Thanks for your update, hopefully I can make some progress now.
> Some easy fix issues:
> 1.Those lines should be removed from spec
> # Requries changes from upstream but can be supported
> ExcludeArch:    ia64
> # Not officially supported by upstream, but possible with some tweaking
> ExcludeArch:    ppc
> # As ppc
> ExcludeArch:    ppc64
> # Unsupported by upstream (although was previously)
> ExcludeArch:    S390
> # Unsupported by upstream
> ExcludeArch:    ARM
> # Unsupported by upstream
> ExcludeArch:    Parisc
> # Unsupported by upstream
> ExcludeArch:    SPARC
> Requires:       %{_bindir}/sed
> Requires:       %{_bindir}/grep
> Requires:       /sbin/runuser
> Requires:       %{__tar}
> Requires:       %{_bindir}/ipcs
> Requires:       %{__awk}
Sure, although I added the ExcludeArch entries because of notes in standards.
When _do_ you use ExcludeArch
> 2. Add those lines before %prep
> %package client
> Conflicts: ingres
> Summary: Local and remote connectivity servers and utilities
> 
> %package server
> Requires: %{name}-client = %{version}-%{release}
> Summary: DBMS server and utilities
> 
> %package devel
> Requires: %{name}-client = %{version}-%{release}
> Summary: Application development
> 
> %package documentation
> Summary: Documentation
> 
> %description client
> Client side runtime and networking components and drivers
> ODBC and JDBC drivers
> 
> %description server
> DBMS server and database utilities
> 
> %description devel
> Embedded SQL precompilers, headers and appliaction development tools
> 
> %description documentation
> Full documentation set in PDF format
Easy enough.
> 
> 3.simply use cat and sed instead of %{__cat}  and %{__sed} 
OK.
> 
> 4.%defattr(-,ingres,ingres,-) should always be %defattr(-,root,root,-)
Even if the vast majority of the files are owned by 'ingres'?
> 
> 5.%post devel
> /sbin/ldconfig %{_libdir}/ingres seems not right
> If the shlibs are in the subdirs of %{_lib}, you should add a file to
> /etc/ld.so.conf.d
I do write a file to /etc/ld.so.conf.d but for some reason when the initial setup commands run in the %post for ingres-client, it can't find the libraries.
I'll have another play.
> 
> 6. Some SPEC references may be useful for you.
> http://cvs.fedoraproject.org/viewvc/rpms/mysql/devel/
> http://cvs.fedoraproject.org/viewvc/rpms/postgresql/devel/  
Thanks, I was looking for these. Will take a look.

(In reply to comment #16)
> 1.%package documentation should be %package doc and should noarch.
OK
> 2. Conflicts: ingres 
> When possible, rpm should be avoid of using conflicts
The problem is, it DOES conflict with ingres. We've had Ingres available as RPMs for a number of years but they don't conform to the standards. Installing both could lead to unpredictable behavior on both side and I'd rather keep that from occurring if I can.
> 3.List files explicit rather than %file -f  
Unless it's absolutely necessary, I'd rather not maintain file lists in the SPEC file separately. There are over 1700 files between the 4 RPMs and the ownership and permission for each file is maintained by one of the build tools. In order to add the file lists to the SPEC files, I would need to do full build of the exact same source outside of RPM, generate the files list, add them to SPEC file and then run the RPM build. This is a fairly large over head for each update and makes maintenance a much larger task. By using the -f flag, I can generate the lists at build time using the existing manifest and they will always be correct.

I'll make the other updates suggested and re-post.

(In reply to comment #17)
> (In reply to comment #15)
> Apologies for the radio silence, I got pulled onto another project for a couple
> of weeks. Thanks for your update, hopefully I can make some progress now.
> > Some easy fix issues:
> > 1.Those lines should be removed from spec
> > # Requries changes from upstream but can be supported
> > ExcludeArch:    ia64
> > # Not officially supported by upstream, but possible with some tweaking
> > ExcludeArch:    ppc
> > # As ppc
> > ExcludeArch:    ppc64
> > # Unsupported by upstream (although was previously)
> > ExcludeArch:    S390
> > # Unsupported by upstream
> > ExcludeArch:    ARM
> > # Unsupported by upstream
> > ExcludeArch:    Parisc
> > # Unsupported by upstream
> > ExcludeArch:    SPARC
> > Requires:       %{_bindir}/sed
> > Requires:       %{_bindir}/grep
> > Requires:       /sbin/runuser
> > Requires:       %{__tar}
> > Requires:       %{_bindir}/ipcs
> > Requires:       %{__awk}
> Sure, although I added the ExcludeArch entries because of notes in standards.
> When _do_ you use ExcludeArch

IMHO the ExcludeArch lines are ok. They are used by the secondary arch SIGs. But I am not sure about the values, iirc it's s390 not S390, but maybe this does not matter. Also the Requires do in general make sense, if they are really needed. But package names instead of the paths are better, e.g. grep is in /bin/grep and not in /usr/bin/grep, unless the paths are hardcoded. But then the package won't work.


> > 4.%defattr(-,ingres,ingres,-) should always be %defattr(-,root,root,-)
> Even if the vast majority of the files are owned by 'ingres'?

I guess it is ok in this case, but it is better to ask on the fedora packaging list. Btw. the spec seems to be gone currently, therefore I did not take a look at it.

(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #15)
> > Apologies for the radio silence, I got pulled onto another project for a couple
> > of weeks. Thanks for your update, hopefully I can make some progress now.
> > > Some easy fix issues:
> > > 1.Those lines should be removed from spec
> > > # Requries changes from upstream but can be supported
> > > ExcludeArch:    ia64
> > > # Not officially supported by upstream, but possible with some tweaking
> > > ExcludeArch:    ppc
> > > # As ppc
> > > ExcludeArch:    ppc64
> > > # Unsupported by upstream (although was previously)
> > > ExcludeArch:    S390
> > > # Unsupported by upstream
> > > ExcludeArch:    ARM
> > > # Unsupported by upstream
> > > ExcludeArch:    Parisc
> > > # Unsupported by upstream
> > > ExcludeArch:    SPARC
> > > Requires:       %{_bindir}/sed
> > > Requires:       %{_bindir}/grep
> > > Requires:       /sbin/runuser
> > > Requires:       %{__tar}
> > > Requires:       %{_bindir}/ipcs
> > > Requires:       %{__awk}
> > Sure, although I added the ExcludeArch entries because of notes in standards.
> > When _do_ you use ExcludeArch
> 
> IMHO the ExcludeArch lines are ok. They are used by the secondary arch SIGs.
> But I am not sure about the values, iirc it's s390 not S390, but maybe this
> does not matter. Also the Requires do in general make sense, if they are really
> needed. But package names instead of the paths are better, e.g. grep is in
> /bin/grep and not in /usr/bin/grep, unless the paths are hardcoded. But then
> the package won't work.

I'll pull them all out for now. If we need them I can re-add them later, I'd rather keep things as clean as possible.

> 
> 
> > > 4.%defattr(-,ingres,ingres,-) should always be %defattr(-,root,root,-)
> > Even if the vast majority of the files are owned by 'ingres'?
> 
> I guess it is ok in this case, but it is better to ask on the fedora packaging
> list. Btw. the spec seems to be gone currently, therefore I did not take a look
> at it.    
OK, thanks. Good to know. 

It seems the spec file and SRPM have fallen victim to a purging process on our FTP server. I'll re-post with the changes, I've requested my staging directory be excluded from the purge. Hopefully this won't happen again. 

Thanks for your help,

Jay

New build uploaded.

SPEC: ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres.spec 4aec3d4562c65bae76cfd28ddec0c864  
SRPM: ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres-10.0.0-4.20100505svn2946.fc12.src.rpm 81bdecaaf3e1c94add5f25969af5ad82

Change log:
* Wed Jun 02 2010 Jay Hankinson <jeremy.hankinson> 10.0.0-4
- Remove ExcludeArch lines and Requires as requested by reviewer
- Move subpackage definitions above pre script
- No need to specify directory when calling ldconfig in client post
- Rename documentation, doc and make noarch
- Add username to runuser commands

Created attachment 419250 [details]
Output from rpmlint - 4.20100505svn2946

Output from: 
rpmlint /devsrc/rpmbuild/SRPMS/ingres-10.0.0-4.20100505svn2946.fc11.src.rpm /devsrc/rpmbuild/RPMS/i586/ingres-*10.0.0-4.20100505svn2946.fc11.i586.rpm /devsrc/rpmbuild/RPMS/noarch/ingres-doc-10.0.0-4.20100505svn2946.fc11.noarch.rpm

Seem to be having an odd problem with ldconfig. If I don't specify the directory (/usr/lib/ingres) when running ldconfig from %post in ingres-client, I get a load of undefined references when running the utilities. I've left it in for now, will investigate further tomorrow and mail the devel list if I need to.

Some suggestions:
1.Do not use  -f in %file, list all them explicitly

2.Scriptlet should be more clear.

See http://fedoraproject.org/wiki/Packaging:ScriptletSnippets

Some scriprlet should be moved to initscript


Please refer mysql SRPM

3. %defattr(-,ingres,ingres,-) -> %defattr(-,root,root,-)

4. Please add a blank file between changelog entities and before %file [subpackagename].

OK, I would do the review, but I can not sponsor you. Is any provenpackager willing and able to support me?

I took the version from June 3rd. Sadly this does not build (at least on F14)

Build runs through until

Assembling "basic" archive:
  Computing file checksums............................................

**Missing file: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/aliasmaptbl

**Missing file: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/ca-big5-cht-2004
.
**Missing file: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/ca-big5-hkscs-cht-2004
.
**Missing file: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/ca-cp852-slav852-latin2-2004
.
**Missing file: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/ca-cp856-hebrew_old-2004

[ lots of messages left out ]

Unable to build release.

Use "buildrel -a" to generate a report of specific problems.  Once
they have been corrected, re-run buildrel to finish generating the release
area.  Use "buildrel -f" to ignore bad files if necessary.

hmm :-/

Last messages from build are:
Looks like the srpm is not quite complete?

Not found: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/utility/unimapcompile
Not found: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/utility/unialscompile
Not found: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/bin/impxml
Not found: /home/mrunge/rpmbuild/BUILD/ingres-10.0.0/build/files/ucharmaps/default

Matthias, please do not assign this review to you, because you are not a sponsor. Jay, to find a sponsor it helps if you comment on other package reviews to show that you are familiar with the Fedora Packaging Guidelines and mention these comments in your review requests.

Till,

I know, I'm not a sponsor. There are lots of packages, where the reviewer is not a sponsor; In comment 25 I asked for a provenpackager to support me: I could do the review, the sponsor could supervize and support (and esp. sponsor Jay). If this way is not accepted or desired, I'll surely step back.

I just wanted to produce some progress here.

Matthias, 

Thanks for the update, I'm actually just about to update the build, addressing the issues you mentioned above. It's caused by building against Xerces 3.x.
I very much appreciated the review offer, it would help even if it isn't official.

RE: Getting sponsored, I do indeed need to post comments on other reviews, I was wanting to feel I understood things a little better first though. Mainly by getting this submission in reasonable shape first.

I'm back on this now after a rather long absence so hopefully I can get things moving again.

Thanks,

Jay

New build uploaded

SPEC: ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres.spec 8c980ce88268711e58e47660fb0a0700
SRPM: ftp://ftp.ingres.com/outgoing/hanje04/srpms/ingres-10.1.0-1.20100920svn3608.fc14.src.rpm 81d4f42048f76dedfb8f0671bc210083

Change Log
* Mon Sep 20 2010 Jay Hankinson <jeremy.hankinson> 10.1.0-1
- Update source and version info for Ingres 10.1 @ svnrev 3608
- Add patch for building aginst Xerces 3

Created attachment 450344 [details]
Output from rpmlint for 10.1.0-1.20100920svn3608

Output from:
rpmlint /var/lib/mock/fedora-14-x86_64/result/*.rpm > ingres-10.1.0-1.20100920svn3608.rpmlint

Disclaimer: I'm not a packager.

I wasn't able to download your SPEC ("get: Access failed: 550 Failed to open file. (ingres.spec)"), but I've looked a bit at the rpmlint output.

You have a lot of non-standard-uid/gid warnings, including for files under /usr, e.g. /usr/libexec/ingres/utility/iiask4it. Is it really necessarily for these files to be owned by someone else besides root?

Also, is to me or there's no reason for the files under /var/lib/ingres/files/ucharmaps/ to change? If so, you should try moving them somewhere under /usr/share.

Sorry, the ftp server has an over zealous cleanup script and keeps removing my files. They've been reposted in the same place so the links should work again.

Not all the files under /usr/libexec/ingres _have_ to be owned by ingres but some of them do. It's allowed as far as the standards are concerned though.

/var/lib/ingres/files/ucharmaps is an odd one. The files in there won't change but we all custom coercions to be defined and they would be put in this directory. There's no easy way to define an alternate location for these files so they need to be in a writable location.

(In reply to comment #34)
> Sorry, the ftp server has an over zealous cleanup script and keeps removing my
> files. They've been reposted in the same place so the links should work again.
They seem to work now.

> Not all the files under /usr/libexec/ingres _have_ to be owned by ingres but
> some of them do. It's allowed as far as the standards are concerned though.
Ok.

> /var/lib/ingres/files/ucharmaps is an odd one. The files in there won't change
> but we all custom coercions to be defined and they would be put in this
> directory. There's no easy way to define an alternate location for these files
> so they need to be in a writable location.
So they are like Apache's icons (/var/www/icons/): you can keep them if you want to, but if don't want them, you can change them.

I'm not sure what's happening with this package, but I went ahead and pulled the srpm and do have a couple of questions.

No parallel make (or jam, I guess)?  Sure takes a long time to build, letting all those cores on my builder sit idle.  I see that jam takes -j; that means that you should be able to use %{?_smp_mflags} to properly parallelize.  Assuming that of course the makefiles/jamfiles are properly written.

Is there a way to get the actual compiler output instead of the sanitized output?  I have a suspicion that the compiler flags are not correct since you don't use %configure and there's no mention of %optflags or $RPM_OPT_FLAGS anywhere in the spec.  Unfortunately the build process doesn't display them so it's tough to tell.  I see dbgbuild.patch but it doesn't use anything close to the proper flags so I'm not sure what it's about.

Why would this require prelink at build time?

Man, it's still building.  (Ten minutes later.)  Still building.  Really, parallel make/jam/whatever.  Please.

The scriptlets for setting up/restarting the service and for adding the users do not correspond to the ones in the packaging guidelines.  
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets
https://fedoraproject.org/wiki/Packaging:UsersAndGroups
Besides, I doubt all of the setup stuff that's done at package install time is really something we want to do.  Why not do all that ahead of time and just put the files into the package?

There are a while bunch of files installed into /usr/bin which are very generically named, like /usr/bin/usermod and seem to have nothing to do with ingres.  I would really suggest prefixing these with something (some use "ing") or otherwise indicating that they're part of your package and not, say, the usermod that's in shadow-utils.

Any progress here?

status update!?