[Monetdb-developers] Problem (and possible fix!) with monetdbd.conf path as specified in Makefile.in
Hello list, I'm currently trying to use the OpenSUSE build service (http://build.openeuse.org), to build packages RPMs for for CentOS and RedHat distributions, and i think I've found a bug in a Makefile for MonetDB. Essentially it looks like the explicit path /etc/tmpfiles.d/monetdbd.conf is used in the Makefile located here: MonetDB-11.5.9/buildtools/conf/Makefile.in ...and the RPM build process doesn't like that. OpenSUSE essentially implicitly enables the "norootdir" option in the spec file (regardless of if it's actually present or not) because RPMs are built is special purpose-built VMs that are provisioned when a "job" to build an RPM is submitted, and the build process doesn't run as root. See here and here for more discussion on this problem (it's a common problem apparently): http://wiki.sipfoundry.org/display/sipXecs/Building+RPM+tips http://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Permission_den... I think the "fix" is as simple as inserting "$(prefix)" into the line in Makefile.in, so that the build path is used to create the temporary folder instead of attempting to writing to the system-wide /etc folder (the build fails on the Makefile's install phase with permission denied errors because of this static path). Am I on to something here? If I'm right, can the Makefile.in file be patched please, adding $(prefix)? -- Thanks, Eric
On 28-11-2011 15:03:56 -0500, Eric G wrote:
Hello list,
I'm currently trying to use the OpenSUSE build service (http://build.openeuse.org), to build packages RPMs for for CentOS and RedHat distributions, and i think I've found a bug in a Makefile for MonetDB.
Essentially it looks like the explicit path /etc/tmpfiles.d/monetdbd.conf is used in the Makefile located here: MonetDB-11.5.9/buildtools/conf/Makefile.in
It's sysconfdir/tmpfiles.d (aparently necessary for systemd)
...and the RPM build process doesn't like that. OpenSUSE essentially implicitly enables the "norootdir" option in the spec file (regardless of if it's actually present or not) because RPMs are built is special purpose-built VMs that are provisioned when a "job" to build an RPM is submitted, and the build process doesn't run as root.
See here and here for more discussion on this problem (it's a common problem apparently):
http://wiki.sipfoundry.org/display/sipXecs/Building+RPM+tips http://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Permission_den...
I think the "fix" is as simple as inserting "$(prefix)" into the line in Makefile.in, so that the build path is used to create the temporary folder instead of attempting to writing to the system-wide /etc folder (the build fails on the Makefile's install phase with permission denied errors because of this static path).
I think the problem here is that $(prefix) (or ${prefix}) is /usr, and etc doesn't belong under /usr, so you could try --sysconfdir='${prefix}/../etc' to make SuSE happy.
Am I on to something here? If I'm right, can the Makefile.in file be patched please, adding $(prefix)?
See above why this doesn't make sense.
On 2011-11-29 08:39, Fabian Groffen wrote:
On 28-11-2011 15:03:56 -0500, Eric G wrote:
Hello list,
I'm currently trying to use the OpenSUSE build service (http://build.openeuse.org), to build packages RPMs for for CentOS and RedHat distributions, and i think I've found a bug in a Makefile for MonetDB.
Essentially it looks like the explicit path /etc/tmpfiles.d/monetdbd.conf is used in the Makefile located here: MonetDB-11.5.9/buildtools/conf/Makefile.in
It's sysconfdir/tmpfiles.d (aparently necessary for systemd)
...and the RPM build process doesn't like that. OpenSUSE essentially implicitly enables the "norootdir" option in the spec file (regardless of if it's actually present or not) because RPMs are built is special purpose-built VMs that are provisioned when a "job" to build an RPM is submitted, and the build process doesn't run as root.
See here and here for more discussion on this problem (it's a common problem apparently):
http://wiki.sipfoundry.org/display/sipXecs/Building+RPM+tips http://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Permission_den...
I think the "fix" is as simple as inserting "$(prefix)" into the line in Makefile.in, so that the build path is used to create the temporary folder instead of attempting to writing to the system-wide /etc folder (the build fails on the Makefile's install phase with permission denied errors because of this static path).
I think the problem here is that $(prefix) (or ${prefix}) is /usr, and etc doesn't belong under /usr, so you could try --sysconfdir='${prefix}/../etc' to make SuSE happy.
Am I on to something here? If I'm right, can the Makefile.in file be patched please, adding $(prefix)?
See above why this doesn't make sense.
In addition to Fabian's remarks, all these paths in the (generated) Makefile.in files are prefixed with $(DESTDIR) (at least, this is the case on Fedora) which the build process is supposed to use for relocating the installation during a make install. -- Sjoerd Mullender
On Tue, Nov 29, 2011 at 3:34 AM, Sjoerd Mullender
In addition to Fabian's remarks, all these paths in the (generated) Makefile.in files are prefixed with $(DESTDIR) (at least, this is the case on Fedora) which the build process is supposed to use for relocating the installation during a make install.
I have a Fedora 15 box, so I'll try using the MonetDB spec file with the 'norootforbuild' keyword added and see if it throws an error... if it builds successfully, then you guys are right, the OpenSUSE build service is doing something funky. If it fails though then there's a problem with $(DESTDIR) By the way, just FYI I'm using the build service but I'm building for CentOS 5 and RedHat 5 - you can target distributions other than SUSE based ones using the build service. I had to modify the spec file and change a couple of "BuildRequires" lines in the spec file, but other than that it seems to get through the compile process OK, it's just when it goes to copy files around later in the build process it fails. -- Eric
participants (3)
-
Eric G -
Fabian Groffen -
Sjoerd Mullender