[opensuse-buildservice] Bug or unimplemented?
I've got a spec file (not on build.opensuse.org, though), that has the following syntax: %{?_with_foo:BuildRequires: foo} With a non-buildservice RPM build, this means that if the macro '_with_foo' is defined, 'foo' is a build requirement. It's a useful syntax; I have to provide a source RPM that can give the user customization options by re-compiling the srpm with various "--with foo" options (or to negate defaults by using "--without foo".) What I'm seeing is the following when I try to build the package using the buildservice: %{_with_foo} is set in the spec file as the default (so RPM sees "BuildRequires: foo") rpmbuild evaluates the statement properly: it requires package 'foo' as a requirement for compilation. The problem is that OBS isn't installing the 'foo' package before starting rpmbuild. When rpmbuild checks that its buildrequires are satisfied, it isn't finding 'foo', and the compile aborts. Obviously, a workaround is to use the %if 0%{?obensuse_bs} # bs-specific part here %endif syntax. But this doesn't seem to be one of the cases where using the syntax is appropriate, as it shouldn't be necessary to know when the buildservice will or won't detect the same build requirements 'rpmbuild' does. -- Troy Telford --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2007-05-24 11:29:03 -0600, Troy Telford wrote:
I've got a spec file (not on build.opensuse.org, though), that has the following syntax:
%{?_with_foo:BuildRequires: foo}
With a non-buildservice RPM build, this means that if the macro '_with_foo' is defined, 'foo' is a build requirement.
It's a useful syntax; I have to provide a source RPM that can give the user customization options by re-compiling the srpm with various "--with foo" options (or to negate defaults by using "--without foo".)
What I'm seeing is the following when I try to build the package using the buildservice: %{_with_foo} is set in the spec file as the default (so RPM sees "BuildRequires: foo")
rpmbuild evaluates the statement properly: it requires package 'foo' as a requirement for compilation.
The problem is that OBS isn't installing the 'foo' package before starting rpmbuild. When rpmbuild checks that its buildrequires are satisfied, it isn't finding 'foo', and the compile aborts.
Obviously, a workaround is to use the
%if 0%{?obensuse_bs} # bs-specific part here %endif
syntax.
But this doesn't seem to be one of the cases where using the syntax is appropriate, as it shouldn't be necessary to know when the buildservice will or won't detect the same build requirements 'rpmbuild' does.
i think that isnt implemented in the spec file parser. but imho ... the obvious workaround ist not %if 0%{?obensuse_bs} but: %if %{?_with_foo} BuildRequires: foo %endif which is essentially the same as: %{?_with_foo:BuildRequires: foo} dont think so? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 24 May 2007, Marcus Rueckert wrote:
i think that isnt implemented in the spec file parser. but imho ... the obvious workaround ist not
%if 0%{?obensuse_bs}
but:
%if %{?_with_foo} BuildRequires: foo %endif
which is essentially the same as: %{?_with_foo:BuildRequires: foo}
D'oh. Yup. So I picked one of the less obvious workarounds... -- Troy Telford Linux Networx ttelford@linuxnetworx.com (801) 649-1356 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, May 24, 2007 at 11:29:03AM -0600, Troy Telford wrote:
I've got a spec file (not on build.opensuse.org, though), that has the following syntax:
%{?_with_foo:BuildRequires: foo}
With a non-buildservice RPM build, this means that if the macro '_with_foo' is defined, 'foo' is a build requirement.
It's a useful syntax; I have to provide a source RPM that can give the user customization options by re-compiling the srpm with various "--with foo" options (or to negate defaults by using "--without foo".)
What I'm seeing is the following when I try to build the package using the buildservice: %{_with_foo} is set in the spec file as the default (so RPM sees "BuildRequires: foo")
%{?xxx: } syntax actually *is* implemented. Maybe your default definition of %{_with_foo} can't be parsed. Can you send me your specfile? Thanks, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Sure; the program itself is LLNL's 'pdsh' (Parallel Distributed Shell; used to execute the same command on a range of nodes in a cluster) The .specfile is a lightly modified version of the one LLNL provides. I use vim's code folding feature quite a bit, so if you see comments to the extent of #{{{ or #}}}, that's just a fold marker. If the "%{?foo:}" syntax is implemented, I'm willing to wager that the problem isn't with the %{?foo:} syntax, but instead with the macros between line(s) 39-46 of the attached .spec. The check(), def(), and def_machines() macros are some of the more arcane macros I've seen. But they help make the code in %build, as well as setting the defaults for the various '--with' options rather clean. On Friday 25 May 2007, you wrote:
On Thu, May 24, 2007 at 11:29:03AM -0600, Troy Telford wrote:
I've got a spec file (not on build.opensuse.org, though), that has the following syntax:
%{?_with_foo:BuildRequires: foo}
With a non-buildservice RPM build, this means that if the macro '_with_foo' is defined, 'foo' is a build requirement.
It's a useful syntax; I have to provide a source RPM that can give the user customization options by re-compiling the srpm with various "--with foo" options (or to negate defaults by using "--without foo".)
What I'm seeing is the following when I try to build the package using the buildservice: %{_with_foo} is set in the spec file as the default (so RPM sees "BuildRequires: foo")
%{?xxx: } syntax actually *is* implemented. Maybe your default definition of %{_with_foo} can't be parsed.
Can you send me your specfile?
Thanks, Michael.
-- Troy Telford
Troy Telford wrote:
If the "%{?foo:}" syntax is implemented, I'm willing to wager that the problem isn't with the %{?foo:} syntax, but instead with the macros between line(s) 39-46 of the attached .spec.
The check(), def(), and def_machines() macros are some of the more arcane macros I've seen. But they help make the code in %build, as well as setting the defaults for the various '--with' options rather clean. ... %{expand: %%define pdsh_with() %%((%{check with})||(%{check without}))%%{nil}}
%(...) expansion isn't implemented in the specfile parser and can't be for security reasons. OTOH why do you need such macros, when you can't set the environment variables anyway? Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 25 May 2007, Michal Marek wrote:
%{expand: %%define pdsh_with() %%((%{check with})||(%{check without}))%%{nil}}
%(...) expansion isn't implemented in the specfile parser and can't be for security reasons.
The security implications are pretty easy to figure out... yeah. Is it possible to sandbox the expansions like you do for the builds? If so, then allowing %() expansions don't have to be any worse than allowing root for builds on obs -- which IIRC is the default unless "#norootforbuild" is in the .spec file At any rate, it would be nice to have it as a configurable option, so those of us who run our own buildservice server can use %() expansions (for use on a private server behind a few firewalls to isolate things).
OTOH why do you need such macros, when you can't set the environment variables anyway?
Michal
A reasonable question. Like many people, I'm moving from a different way of building packages to the build service. The buildservice just has a number of compelling features that are beneficial; it's certainly why I'm moving to it, and why I set up my own buildservice server. However, it's frustrating to when a package won't build inside the BuildService, but has no problems when compiled manually. I am aware that with the BuildService, you can't define environment variables prior to RPM building, or supply "--with <foo>" options to rpmbuild. For 99+% of use cases, this is fine. One of my packages (for example) can result a few hundred different variations from the same .specfile. Different compilers, libraries can be used, for example. It's necessary for me (business reasons) to provide such flexibility. That way, if one of my users has requirements that aren't met by the pre-compiled package, they can easily compile an RPM that does suit their needs (using the src.rpm). The alternative (that I'm trying to move away from) is that my users will manually build from source code-- giving up all the advantages of a package manager like RPM. It was a support nightmare that I'd really not go back to... I certainly would like to add a feature to the build service so that a maintainer can specify options (or better, a list of options to be used in an iterative number of builds on the same package); but that'll take a while to implement. -- Troy Telford --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Fri, May 25, 2007 at 04:58:30PM -0600, Troy Telford wrote:
On Friday 25 May 2007, Michal Marek wrote:
%{expand: %%define pdsh_with() %%((%{check with})||(%{check without}))%%{nil}}
%(...) expansion isn't implemented in the specfile parser and can't be for security reasons.
The security implications are pretty easy to figure out... yeah. Is it possible to sandbox the expansions like you do for the builds?
No, that would be much too slow.
A reasonable question.
Like many people, I'm moving from a different way of building packages to the build service. The buildservice just has a number of compelling features that are beneficial; it's certainly why I'm moving to it, and why I set up my own buildservice server. However, it's frustrating to when a package won't build inside the BuildService, but has no problems when compiled manually.
I am aware that with the BuildService, you can't define environment variables prior to RPM building, or supply "--with <foo>" options to rpmbuild. For 99+% of use cases, this is fine.
One of my packages (for example) can result a few hundred different variations from the same .specfile. Different compilers, libraries can be used, for example. It's necessary for me (business reasons) to provide such flexibility. That way, if one of my users has requirements that aren't met by the pre-compiled package, they can easily compile an RPM that does suit their needs (using the src.rpm).
Yeah, but why environment variables? If you don't want to use --with or --without, you can just define the %with_xxx macro in your .rpmmacros file. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Sunday 27 May 2007, Michael Schroeder wrote:
On Fri, May 25, 2007 at 04:58:30PM -0600, Troy Telford wrote:
On Friday 25 May 2007, Michal Marek wrote:
%{expand: %%define pdsh_with() %%((%{check with})||(%{check without}))%%{nil}}
%(...) expansion isn't implemented in the specfile parser and can't be for security reasons.
The security implications are pretty easy to figure out... yeah. Is it possible to sandbox the expansions like you do for the builds?
No, that would be much too slow.
I thought as much, but I figured I may as well ask.
Yeah, but why environment variables? If you don't want to use --with or --without, you can just define the %with_xxx macro in your .rpmmacros file.
Mainly because providing multiple paths to get to the same end is comforting to some users -- I can only guess how addicted those users must be to Perl... I'm not particularly attached to using environment variables myself; they feel like a sloppy way to do the job. -- Troy Telford --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Fri, May 25, 2007 at 09:43:56AM -0600, Troy Telford wrote:
Sure; the program itself is LLNL's 'pdsh' (Parallel Distributed Shell; used to execute the same command on a range of nodes in a cluster)
The .specfile is a lightly modified version of the one LLNL provides.
I use vim's code folding feature quite a bit, so if you see comments to the extent of #{{{ or #}}}, that's just a fold marker.
If the "%{?foo:}" syntax is implemented, I'm willing to wager that the problem isn't with the %{?foo:} syntax, but instead with the macros between line(s) 39-46 of the attached .spec.
The check(), def(), and def_machines() macros are some of the more arcane macros I've seen. But they help make the code in %build, as well as setting the defaults for the various '--with' options rather clean.
Two problems: - %{expand} is not implemented (this is fixable) - %() can't work Sorry, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (4)
-
Marcus Rueckert -
Michael Schroeder -
Michal Marek -
Troy Telford