Mailinglist Archive: opensuse-buildservice (233 mails)

< Previous Next >
Re: [opensuse-buildservice] Bug or unimplemented?
  • From: Troy Telford <ttelford.groups@xxxxxxxxx>
  • Date: Fri, 25 May 2007 16:58:30 -0600
  • Message-id: <200705251658.31137.ttelford.groups@xxxxxxxxx>
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 

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 
Troy Telford
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups