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