Forcing a script to bomb, etc.

[Philip Prindeville]

So... a few miscellaneous questions.

First, where is the current authoritative documentation? I've not found
%{!? documented anywhere.

Second, is there a guide to what macros are common on all platforms,
like %{with and %{without?

Third, can I force an RPM to error with a message is a standard fashion,
if it finds (for instance) that it's being built with a combination of
incompatible --with options?

Fourth, is it philosophically preferable to have a package build by
default with everything, but have the package turn stuff off with
--without xxx, or build the smallest supportable package, but turn
things on via rpmbuild --with arguments?

Because I recently got flamed for updating proftpd's .spec file to
disable most things, and changing the new default behavior to have you
turn stuff on individually (even though the top of the comments section
of the .spec file says "this is how you build with everything".... RTFSF
(RTF-.spec file).

Lastly, where's the documentation on writing and using macros that take
arguments?

-Philip

[Michael Jennings]

On Friday, 12 October 2007, at 10:10:13 (-0700),

Post by Philip Prindeville
So... a few miscellaneous questions.
First, where is the current authoritative documentation? I've not found
%{!? documented anywhere.

/usr/share/doc/rpm-*/conditionalbuilds

Post by Philip Prindeville
Second, is there a guide to what macros are common on all platforms, like
%{with and %{without?

Not really, but the stuff in /usr/share/doc is a good start.

Post by Philip Prindeville
Third, can I force an RPM to error with a message is a standard
fashion, if it finds (for instance) that it's being built with a
combination of incompatible --with options?

It's a shell script. Do whatever you like.

Post by Philip Prindeville
Fourth, is it philosophically preferable to have a package build by
default with everything, but have the package turn stuff off with
--without xxx, or build the smallest supportable package, but turn
things on via rpmbuild --with arguments?

It's your package; do it however you want. I prefer to default to
building everything and require manual intervention to turn things
off. Makes things more autobuilder-friendly.

Post by Philip Prindeville
Lastly, where's the documentation on writing and using macros that take
arguments?

See above.

Michael

[Philip Prindeville]

Post by Michael Jennings
On Friday, 12 October 2007, at 10:10:13 (-0700),

Post by Philip Prindeville
So... a few miscellaneous questions.
First, where is the current authoritative documentation? I've not found
%{!? documented anywhere.

/usr/share/doc/rpm-*/conditionalbuilds

Ok, thanks. Looking at the example:

%if %{?_with_ssl:1}%{!?_with_ssl:0}

that's a little more complicated than it needs to be, isn't it?

I've seen:

%if 0%{?_with_ssl:1}

And that seems to work equally well...

Post by Michael Jennings

Post by Philip Prindeville
Second, is there a guide to what macros are common on all platforms, like
%{with and %{without?

Not really, but the stuff in /usr/share/doc is a good start.

Sigh.

Post by Michael Jennings

Post by Philip Prindeville
Third, can I force an RPM to error with a message is a standard
fashion, if it finds (for instance) that it's being built with a
combination of incompatible --with options?

It's a shell script. Do whatever you like.

Right, but I don't want to capture the shell exit value of %(...) as an
expression.... I want to bomb out.

I suppose I could have:

%prep
...
%if !<some sanity tests here>
echo "This can't possibly be correct." 1>&2
exit 1
%endif

Post by Michael Jennings

Post by Philip Prindeville
Fourth, is it philosophically preferable to have a package build by
default with everything, but have the package turn stuff off with
--without xxx, or build the smallest supportable package, but turn
things on via rpmbuild --with arguments?

It's your package; do it however you want. I prefer to default to
building everything and require manual intervention to turn things
off. Makes things more autobuilder-friendly.

That's what I wanted to do, but it got slapped down.

We could add an AutobuilderHint: field to the header that wouldn't do
anything, but that autobuilders could grovel out and use as the default
set of arguments...

Post by Michael Jennings

Post by Philip Prindeville
Lastly, where's the documentation on writing and using macros that take
arguments?

See above.
Michael

doc/macros it looks like.

-Philip

[Michael Jennings]

On Friday, 12 October 2007, at 15:57:01 (-0700),

Post by Philip Prindeville
%if %{?_with_ssl:1}%{!?_with_ssl:0}
that's a little more complicated than it needs to be, isn't it?
%if 0%{?_with_ssl:1}
And that seems to work equally well...

Either will work. "More clear" vs. "more complicated" is often in the
eye of the beholder.

Post by Philip Prindeville
Right, but I don't want to capture the shell exit value of %(...)
as an expression.... I want to bomb out.

I never said anything about %(...)

Post by Philip Prindeville
%prep
...
%if !<some sanity tests here>
echo "This can't possibly be correct." 1>&2
exit 1
%endif

If you think that's necessary.

Post by Philip Prindeville
That's what I wanted to do, but it got slapped down.

You'll learn over time whose advice to listen to and whose to ignore.
You may have chosen poorly. :-)

Post by Philip Prindeville
We could add an AutobuilderHint: field to the header that wouldn't
do anything, but that autobuilders could grovel out and use as the
default set of arguments...

Such a tag would be completely non-portable and entirely outside the
scope of anything RPM should be managing.

Michael

[Philip Prindeville]

Post by Michael Jennings
On Friday, 12 October 2007, at 15:57:01 (-0700),

Post by Philip Prindeville
%if %{?_with_ssl:1}%{!?_with_ssl:0}
that's a little more complicated than it needs to be, isn't it?
%if 0%{?_with_ssl:1}
And that seems to work equally well...

Either will work. "More clear" vs. "more complicated" is often in the
eye of the beholder.

Well, in this case, "more likely to be mistyped or having a missing
curly brace" is the metric of undesirability. ;-)

Post by Michael Jennings

Post by Philip Prindeville
Right, but I don't want to capture the shell exit value of %(...)
as an expression.... I want to bomb out.

I never said anything about %(...)

Post by Philip Prindeville
%prep
...
%if !<some sanity tests here>
echo "This can't possibly be correct." 1>&2
exit 1
%endif

If you think that's necessary.

I'm open to suggestions of a better way.

Post by Michael Jennings

Post by Philip Prindeville
That's what I wanted to do, but it got slapped down.

You'll learn over time whose advice to listen to and whose to ignore.
You may have chosen poorly. :-)

Well, as the project owner, he pretty much gets the final word.

Post by Michael Jennings

Post by Philip Prindeville
We could add an AutobuilderHint: field to the header that wouldn't
do anything, but that autobuilders could grovel out and use as the
default set of arguments...

Such a tag would be completely non-portable and entirely outside the
scope of anything RPM should be managing.
Michael

[Michael Jennings]

On Friday, 12 October 2007, at 16:47:40 (-0700),

Post by Philip Prindeville
Well, in this case, "more likely to be mistyped or having a missing
curly brace" is the metric of undesirability. ;-)

Not necessarily when illustrating a concept. :-)

Post by Philip Prindeville
I'm open to suggestions of a better way.

Don't. Let the build fail if something is poorly configured.

Post by Philip Prindeville

Post by Michael Jennings
You'll learn over time whose advice to listen to and whose to ignore.
You may have chosen poorly. :-)

Well, as the project owner, he pretty much gets the final word.

Upstream authors who understand and are good at packaging are the
exception, not the rule. But for your package, you have final say.

For upstream packages, it's usually best to have soft build
dependencies for all the extras and make sure that the spec file is
written in such a way as to build properly in as many cases as
possible (i.e., with or without the extra fluff).

Michael