Mailinglist Archive: opensuse-packaging (171 mails)

< Previous Next >
Re: [opensuse-packaging]
Nelson Marques <nmo.marques@xxxxxxxxx> 於 2012-3-8 上午10:10 寫道:

2012/3/7 Marguerite Su <i@xxxxxxxxxxxxx>:
Hi, all,

(I don't know if it's right to post it here, but I think it must be
someone among us who wrote the wiki page)

I'm translating specfile_guide wiki to Chinese. But I can't understand
the following:

"If the spec file contains conditional dependencies selected based on
presence of optional --with(out) foo arguments to rpmbuild, build the
source RPM to be submitted with tn he default options, ie. so that none
of these arguments are present in the rpmbuild command line. The
reason is that those requirements get "serialized" into the resulting
source RPM, ie. the conditionals no longer apply."

it seems initial writer copied it from Fedora. can anyone help me
understanding this?

#1 I know what conditional dependencies are.

I'm not really sure because it looks to me that the text makes no
sense and speaks of 2 different things:

1) Dependencies: Practical case... On Banshee we use a single spec to
build banshee for all supported platforms. We use conditionals to
identify the platform and according to it we can pass extra
arguments... For example if we want to enable the support of libgpod
for openSUSE >= 11.4. This done through the following conditional:

%configure --disable static \
%if 0%{?suse_version} >= 1140
--with-libgpod \

So if we are building it on openSUSE 1140 or higher it enables
support for libgpod. If you do this you must also declare the
dependency as a "BuildRequires: libgpod-devel", also under a
conditional (because it probably doesn't support openSUSE < 1130).
This is one part of the message.

2) Building an SRPM: SRPMs are built with 'rpmbuild' which supports
extra definitions that sometimes can trigger conditionals on the spec.
If you have an SRPM and want to rebuild it on a different environment,
sometimes you can passe those conditionals by command line, for

# rpmbuild --rebuild banshee-2.2.0-1.1.src.rpm --define
'suse_version: "1140"'

This would allow to pass the suse_version value to the build process
so it would trigger the macro (the dependency should be installed

I think this is what the author is trying to document.

If you need an example, try maybe this (this is deprecated but
documents a very similar operation... kernel modules are still build
this way for RHEL5 and clones):

If you scroll to the bottom you see some examples invoking rpmbuild
with extra options to change conditionals inside of the SRPM...
Hope this helps.

#2 “build the source RPM to be submitted" why build before submission?
if builds locally, why submit the SRPM instead of the whole project?

This might be related to Fedora and makes sense. Fedora package
reviews (for non verified packagers) require the .spec file and the
SRPM. Koji itself, equivalent to OBS in openSUSE takes packages to
build in the form of SRPMs.

Hi, thanks a lot! XOXO, NM,

This Koji reference explains the whole thing.

It means, when building the SRPM to be submitted to Koji, you don't need to
"rpmbuild -ba *.spec --with condition 1" to show that it's a package contains
conditional dependencies. Just build with "rpmbuild -ba *.spec". Because
conditions are already in spec which will be packaged into SRPM for sure. Do
not apply any conditions to the local rpmbuild. Conditions will be
automatically solved by different fedora repositories and architectures.

So this wiki item is totally nonsense for our openSuSE packagers. Thus it
should be either rewritten or deleted. I have done that in Chinese, maybe later
I could translate it back to English.

Big thanks again!


從我的 iPad 傳送

#3 "are presented in the rpmbuild command line" where the rpmbuild
command line is? I never see them on OBS, although I know I can "rpm
-ba *.spec --with condition 1 --without condition 2"

Check the example above... You don't see this on OBS because this kind
of stuff is well hidden. You can most likely compare it with OBS
"Project Config"... It's mainly overriding stuff on the spec file or
redefining values.

This is at least the idea I got from the text. Hope it helps.

#4 I can't understand the sentence from "the reason" to the end.

Can anyone give me some hints? or a plain English example?
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups