[opensuse-packaging] Where do the macros "BUILD_ORIG" and "BUILD_ORIG_ADDON" come from?
Putting %dump in the spec file doesn't show up anything. Another thing, what's the point of a macro like %glib2_gsettings_schema_requires which expands to Requires(post): glib2-tools and Requires(postun): glib2-tools and breaks the 11.3 build of a package? ie. gstreamer-0_10-plugins-bad. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le lundi 31 janvier 2011, à 02:44 +0200, Dave Plater a écrit :
Putting %dump in the spec file doesn't show up anything.
It's to make it possible to build the gstreamer packages in packman (or any other places) with the codecs that we can't build in the build service, while still sharing the same source packages.
Another thing, what's the point of a macro like %glib2_gsettings_schema_requires which expands to Requires(post): glib2-tools and Requires(postun): glib2-tools and breaks the 11.3 build of a package? ie. gstreamer-0_10-plugins-bad.
It's useful in case this requirement changes, either because the utility that lives now in glib2-tools moves elsewhere or because something else is also needed. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/31/2011 09:29 AM, Vincent Untz wrote:
Le lundi 31 janvier 2011, à 02:44 +0200, Dave Plater a écrit :
Putting %dump in the spec file doesn't show up anything.
It's to make it possible to build the gstreamer packages in packman (or any other places) with the codecs that we can't build in the build service, while still sharing the same source packages.
It's basically like a bcond but I still don't understand where it's definition lives. It's a pity there isn't some sort of memo or something that's circulated to package maintainers with a brief note about new features like this. Anyway I've disabled the gstreamers builds for the openSUSE versions that fail. Is there some sort of liaison with packman and videolan, it's quite an important thing for multimedia? At least the gstreamer spec files are easier to work with, have a look at the xine-lib one, it's overloaded with bconds and %if suse_versions and very confusing.
Another thing, what's the point of a macro like %glib2_gsettings_schema_requires which expands to Requires(post): glib2-tools and Requires(postun): glib2-tools and breaks the 11.3 build of a package? ie. gstreamer-0_10-plugins-bad.
It's useful in case this requirement changes, either because the utility that lives now in glib2-tools moves elsewhere or because something else is also needed.
Vincent
glib2-tools must be gnome? They don't exist for 11.3 which is still current. Btw I'm about to try pushing lv2core and slv2 to factory, I see it's wanted by gstreamer plugins bad, do you know of any other packages that can use LV2 plugin support? Lv2core and slv2 have been in multimedia:libs for a while, I just stupidly wasted time trying to get the redland perl bindings to install in vendor_arch instead of site_arch, I've disabled them with a bcond, lv2config only needs the python bindings. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater wrote:
On 01/31/2011 09:29 AM, Vincent Untz wrote:
Le lundi 31 janvier 2011, à 02:44 +0200, Dave Plater a écrit :
Putting %dump in the spec file doesn't show up anything.
It's to make it possible to build the gstreamer packages in packman (or any other places) with the codecs that we can't build in the build service, while still sharing the same source packages.
It's basically like a bcond but I still don't understand where it's definition lives.
Nowhere :-) You can define %BUILD_ORIG and %BUILD_ORIG_ADDON in your ~/.rpmmacros, pass the definition to the build script via --define or put it in the project config. xine uses bconds¹ instead. It would be nice if the method could finally be unified.
Is there some sort of liaison with packman and videolan, it's quite an important thing for multimedia?
AFAIK only for xine-lib. It would be desirable to combine efforts on gstreamer and other dupliated spec files as well though.
At least the gstreamer spec files are easier to work with, have a look at the xine-lib one, it's overloaded with bconds and %if suse_versions and very confusing.
Well, xine has lots of features, can be compiled for older distros still and the spec file is identical on Factory and packman ... cu Ludwig [1] http://lizards.opensuse.org/2008/09/12/conditional-features-aka-use-flags/ -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/31/2011 11:09 AM, Ludwig Nussel wrote:
Dave Plater wrote:
On 01/31/2011 09:29 AM, Vincent Untz wrote:
Le lundi 31 janvier 2011, à 02:44 +0200, Dave Plater a écrit :
Putting %dump in the spec file doesn't show up anything.
It's to make it possible to build the gstreamer packages in packman (or any other places) with the codecs that we can't build in the build service, while still sharing the same source packages.
It's basically like a bcond but I still don't understand where it's definition lives.
Nowhere :-) You can define %BUILD_ORIG and %BUILD_ORIG_ADDON in your ~/.rpmmacros, pass the definition to the build script via --define or put it in the project config. xine uses bconds¹ instead. It would be nice if the method could finally be unified.
bcond lives in /usr/lib/rpm/macros, when I came across it in xine-lib I found averything I needed to understand it there. BUILD_ORIG otoh isn't in my 11.3 systems /etc/rpm or /usr/lib/rpm and wasn't even part of a %dunp in an osc build openSUSE_Factory, I haven't tried an online one but if the macro works it must be hard coded into rpm or something. I've seen it for the first time in gstreamer plugins bad just after I'd tried to get the update service running unsuccessfully and thought I'd broken the 11.3 build somehow due to an error that appears at the beginning of the rpmbuild part of the build.
Is there some sort of liaison with packman and videolan, it's quite an important thing for multimedia?
AFAIK only for xine-lib. It would be desirable to combine efforts on gstreamer and other dupliated spec files as well though.
At least the gstreamer spec files are easier to work with, have a look at the xine-lib one, it's overloaded with bconds and %if suse_versions and very confusing.
Well, xine has lots of features, can be compiled for older distros still and the spec file is identical on Factory and packman ...
cu Ludwig
[1] http://lizards.opensuse.org/2008/09/12/conditional-features-aka-use-flags/
I haven;t been around packaging long enough to have picked that up, I could most probably browse the openSUSE site for days and not find it, thanks for the link. I've decided to leave xine-lib alone, I have a funny feeling that I could cause trouble by submitting an update to factory besides it seems to work remarkably well :-X Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 30/01/11 21:44, Dave Plater escribió:
Putting %dump in the spec file doesn't show up anything. Another thing, what's the point of a macro like %glib2_gsettings_schema_requires which expands to Requires(post): glib2-tools and Requires(postun): glib2-tools and breaks the 11.3 build of a package? ie. gstreamer-0_10-plugins-bad. Thanks Dave P
Use %{?glib2_gsettings_schema_requires: %glib2_gsettings_schema_requires} In the spec file. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 31/01/11 12:52, Cristian Rodríguez wrote:
Use
%{?glib2_gsettings_schema_requires: %glib2_gsettings_schema_requires}
In the spec file.
Isn't %{?glib2_gsettings_schema_requires} enough? -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/31/2011 05:06 PM, Pavol Rusnak wrote:
On 31/01/11 12:52, Cristian Rodríguez wrote:
Use
%{?glib2_gsettings_schema_requires: %glib2_gsettings_schema_requires}
In the spec file.
Isn't %{?glib2_gsettings_schema_requires} enough?
It works in gstreamer and if it ain't broke don't fix it. I'm in favour of less key presses. In fact jokes aside, the advice is don't use braces if the macro takes input and use braces otherwise but what is the purpose of the leading "?"? Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 31/01/11 15:37, Dave Plater wrote:
On 01/31/2011 05:06 PM, Pavol Rusnak wrote:
On 31/01/11 12:52, Cristian Rodríguez wrote:
Use
%{?glib2_gsettings_schema_requires: %glib2_gsettings_schema_requires}
In the spec file.
Isn't %{?glib2_gsettings_schema_requires} enough?
It works in gstreamer and if it ain't broke don't fix it. I'm in favour of less key presses. In fact jokes aside, the advice is don't use braces if the macro takes input and use braces otherwise but what is the purpose of the leading "?"? Dave P
I'm by no means an expert, but I'm surprised people are packaging missing this info ... Here's the basics / what I know: Braces are generally recommended for anything but the most trivial macros and (possibly) macros with arguments, on their own line. Define a macro with "%define macro value", use a macro with "%{macro}" or one of the following: %{?macro} expands to the value of %macro if %macro is defined, and "" (empty string) if it isn't. similarly %{?macro:foo} expands to "foo" if %macro is defined. and the opposite is %{!?macro:bar} which expands to "bar" if %macro isn't defined. These can be nested. For example I've used %{?make_install} %{!?make_install:%makeinstall} which will work if make_install OR makeinstall is defined. This also should explain the common idiom %if 0%{?suse_version} If just "%if %{suse_version}", when trying to build on a non-suse distro, rpm would complain about an unrecognized macro. If just "%if %{?suse_version}" was used, rpm would see only %if "" (empty string) and complain about missing argument to %if. %{?macro:%macro} is clearly redundant given the above definitions; so in the above case %{?glib2_gsettings_schema_requires} should be sufficient. This sounds distro-specific so the leading "?" is a good idea - no errors on distro's without the macro defined. Packagers: If you haven't already, at least skim through the interesting bits of "Maximum RPM" http://www.rpm.org/max-rpm/ and the packager-relevant docs at http://rpm.org/wiki/Docs. It would help to improve packager-focused documentation ... maybe an rpm macros / spec file "cheat sheet" could come with the OBS documentation? Regards, Tejas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/31/2011 09:16 PM, Tejas Guruswamy wrote:
I'm by no means an expert, but I'm surprised people are packaging missing this info ... Here's the basics / what I know:
Braces are generally recommended for anything but the most trivial macros and (possibly) macros with arguments, on their own line. Define a macro with "%define macro value", use a macro with "%{macro}" or one of the following: %{?macro} expands to the value of %macro if %macro is defined, and "" (empty string) if it isn't. similarly %{?macro:foo} expands to "foo" if %macro is defined. and the opposite is %{!?macro:bar} which expands to "bar" if %macro isn't defined. These can be nested.
For example I've used %{?make_install} %{!?make_install:%makeinstall} which will work if make_install OR makeinstall is defined.
This also should explain the common idiom %if 0%{?suse_version} If just "%if %{suse_version}", when trying to build on a non-suse distro, rpm would complain about an unrecognized macro. If just "%if %{?suse_version}" was used, rpm would see only %if "" (empty string) and complain about missing argument to %if.
%{?macro:%macro} is clearly redundant given the above definitions; so in the above case %{?glib2_gsettings_schema_requires} should be sufficient. This sounds distro-specific so the leading "?" is a good idea - no errors on distro's without the macro defined.
I spent quite a few days googling and researching, which lead to me spending quite a while on fedora's packaging as well, the openSUSE packaging portal is improving day by day btw. The http://www.rpm.org/max-rpm-snapshot/ bookmark (it was me who changed the old wiki to point to the snapshot version) I've had for a while since my first blender maintainance and never found anything about "?". Your explanation explains why rpmlint complains about "%if %suse_version <= 1020" but doesn't complain about "%if 0%{?suse_version} <= 1020" rpm in <= 1020 most probably won't see the macro at all? The invert "!" next to "?" is a new one, I would only use "!" in "%if ! %{with foo}" does it invert when used inside the braces to the left of "?"? I don't understand the usage of the colon ":" inside the macro either, I've seen it used but it doesn't seem to do anything except obfuscate the macro a bit more than normal. Last but not least, like a small boy asking his mother where babies come from, where is "BUILD_ORIG" and "BUILD_ORIG_ADDON" defined, I still haven't tried an online build %dump but I've looked everywhere else, including a local factory build with %dump. When I first found the use of %bcond I could find /usr/lib/rpm /etc/rpm grep and I found a very good explanation (I was able to fix the original packagers use of it) but the only answer I've had for the BUILD macros (are they macros?) is it's there, which to me is the same as "the stork drops them down the chimney. I now fully understand the use of "?". Thanks very much, knowledge is my heroin. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 01/02/11 10:37, Dave Plater wrote:
On 01/31/2011 09:16 PM, Tejas Guruswamy wrote:
... %{?macro} expands to the value of %macro if %macro is defined, and "" (empty string) if it isn't. similarly %{?macro:foo} expands to "foo" if %macro is defined. and the opposite is %{!?macro:bar} which expands to "bar" if %macro isn't defined. These can be nested. ...
I spent quite a few days googling and researching, which lead to me spending quite a while on fedora's packaging as well, the openSUSE packaging portal is improving day by day btw. The http://www.rpm.org/max-rpm-snapshot/ bookmark (it was me who changed the old wiki to point to the snapshot version) I've had for a while since my first blender maintainance and never found anything about "?". Your explanation explains why rpmlint complains about "%if %suse_version <= 1020" but doesn't complain about "%if 0%{?suse_version} <= 1020" rpm in <= 1020 most probably won't see the macro at all? Yeah, max-rpm is missing info on macro conditionals. But to answer what seems to be your question. On a suse distro, %if 0%{?suse_version} <= 1020 expands to (e.g. on 11.1) %if 01110 <= 1020 giving the expected result - false (leading zero is ignored for arithmetic comparison)
But on a non-suse distro, %if 0%{?suse_version} <= 1020 expands to %if 0 <= 1020 so no errors, but it will be true! Maybe not what you expected. So be careful! The behaviour on non-suse distros could depend on the direction of the comparison (greater than/less than)! A (slightly unwieldy) construct which fixes this to be true ONLY on suse-distros satisfying the version requirement, and not on anything else: %if %{?suse_version:%{suse_version} <= 1020} %{!?suse_version:0} but most people don't bother to check for this.
The invert "!" next to "?" is a new one, I would only use "!" in "%if ! %{with foo}" does it invert when used inside the braces to the left of "?"? I don't understand the usage of the colon ":" inside the macro either, I've seen it used but it doesn't seem to do anything except obfuscate the macro a bit more than normal.
The colon is very useful. Try it: > rpm --eval '%{?suse_version:foo} %{!?blah:bar}' # foo bar where ofc %suse_version is defined, and %blah is not defined. The construct %{?foo:bar} can be thought of as a contracted form of the if-statement, usable on one line and as an argument to something else. if %{foo} bar <--- note this could be a macro too ( %{?foo:%{?bar:blah}} is fine, it's just like nested if's ) else "" (empty string) endif and conversely %{!?foo:bar} is like if ! %{foo} (not foo) bar else "" (empty string) endif It's a little bit like the C-style ternary operator: ( cond ? foo : bar ) is equivalent to if(cond); then foo; else bar
Last but not least, like a small boy asking his mother where babies come from, where is "BUILD_ORIG" and "BUILD_ORIG_ADDON" defined, I still haven't tried an online build %dump but I've looked everywhere else, including a local factory build with %dump. When I first found the use of %bcond I could find /usr/lib/rpm /etc/rpm grep and I found a very good explanation (I was able to fix the original packagers use of it) but the only answer I've had for the BUILD macros (are they macros?) is it's there, which to me is the same as "the stork drops them down the chimney.
If they are being used without %'s, i.e. "BUILD_ORIG" and not "%BUILD_ORIG", then they are shell environment variables, not rpm macros. No idea where the default would come from in that case. If they are macros, it seems the packager is expected to define it on the command-line when running rpmbuild (see the --define option) or in his ~/.rpmmacros. On the OBS it could be defined in a prjconf. Which means in the default state it is undefined. See Ludwig's earlier answer.
I now fully understand the use of "?". Thanks very much, knowledge is my heroin. Dave P
HTH Regards Tejas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/01/2011 01:58 PM, Tejas Guruswamy wrote:
On 01/02/11 10:37, Dave Plater wrote:
On 01/31/2011 09:16 PM, Tejas Guruswamy wrote:
... %{?macro} expands to the value of %macro if %macro is defined, and "" (empty string) if it isn't. similarly %{?macro:foo} expands to "foo" if %macro is defined. and the opposite is %{!?macro:bar} which expands to "bar" if %macro isn't defined. These can be nested. ...
I spent quite a few days googling and researching, which lead to me spending quite a while on fedora's packaging as well, the openSUSE packaging portal is improving day by day btw. The http://www.rpm.org/max-rpm-snapshot/ bookmark (it was me who changed the old wiki to point to the snapshot version) I've had for a while since my first blender maintainance and never found anything about "?". Your explanation explains why rpmlint complains about "%if %suse_version <= 1020" but doesn't complain about "%if 0%{?suse_version} <= 1020" rpm in <= 1020 most probably won't see the macro at all?
Yeah, max-rpm is missing info on macro conditionals. But to answer what seems to be your question. On a suse distro, %if 0%{?suse_version} <= 1020 expands to (e.g. on 11.1) %if 01110 <= 1020 giving the expected result - false (leading zero is ignored for arithmetic comparison)
But on a non-suse distro, %if 0%{?suse_version} <= 1020 expands to %if 0 <= 1020 so no errors, but it will be true! Maybe not what you expected. So be careful! The behaviour on non-suse distros could depend on the direction of the comparison (greater than/less than)!
A (slightly unwieldy) construct which fixes this to be true ONLY on suse-distros satisfying the version requirement, and not on anything else: %if %{?suse_version:%{suse_version} <= 1020} %{!?suse_version:0} but most people don't bother to check for this.
The invert "!" next to "?" is a new one, I would only use "!" in "%if ! %{with foo}" does it invert when used inside the braces to the left of "?"? I don't understand the usage of the colon ":" inside the macro either, I've seen it used but it doesn't seem to do anything except obfuscate the macro a bit more than normal.
The colon is very useful. Try it: > rpm --eval '%{?suse_version:foo} %{!?blah:bar}' # foo bar
where ofc %suse_version is defined, and %blah is not defined.
The construct %{?foo:bar} can be thought of as a contracted form of the if-statement, usable on one line and as an argument to something else. if %{foo} bar <--- note this could be a macro too ( %{?foo:%{?bar:blah}} is fine, it's just like nested if's ) else "" (empty string) endif
and conversely %{!?foo:bar} is like if ! %{foo} (not foo) bar else "" (empty string) endif
It's a little bit like the C-style ternary operator: ( cond ? foo : bar ) is equivalent to if(cond); then foo; else bar
Last but not least, like a small boy asking his mother where babies come from, where is "BUILD_ORIG" and "BUILD_ORIG_ADDON" defined, I still haven't tried an online build %dump but I've looked everywhere else, including a local factory build with %dump. When I first found the use of %bcond I could find /usr/lib/rpm /etc/rpm grep and I found a very good explanation (I was able to fix the original packagers use of it) but the only answer I've had for the BUILD macros (are they macros?) is it's there, which to me is the same as "the stork drops them down the chimney.
If they are being used without %'s, i.e. "BUILD_ORIG" and not "%BUILD_ORIG", then they are shell environment variables, not rpm macros. No idea where the default would come from in that case. If they are macros, it seems the packager is expected to define it on the command-line when running rpmbuild (see the --define option) or in his ~/.rpmmacros. On the OBS it could be defined in a prjconf. Which means in the default state it is undefined. See Ludwig's earlier answer.
I now fully understand the use of "?". Thanks very much, knowledge is my heroin. Dave P
HTH
Regards Tejas
I'll experiment with "!" and ":" later on the matter of "BUILD_ORIG" it's not defined and it's used as a macro ie. taken from "gstreamer-0_10-plugins-bad.spec" : %if 0%{?BUILD_ORIG_ADDON} Provides: patched_subset %else Provides: %{name}-orig-addon = %{version} Obsoletes: %{name}-orig-addon %endif And with rpmbuild -D 'BUILD_ORIG 1' you get the unpatched build. It must be an environment variable defined by rpm, I must try a "set|grep BUILD_ORIG" inside a spec file rpm --eval="BUILD_ORIG 1" and rpm --querytags|grep BUILD_ORIG shows nothing. Anyway enough time spent, it works which is what really matters, time to put it on the back burner and I will find it later. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Cristian Rodríguez -
Dave Plater -
Ludwig Nussel -
Pavol Rusnak -
Tejas Guruswamy -
Vincent Untz