How to produce platform-specific and platform-independent RPM subpackages from one .spec?

Asked 9/1, 2015 at 14:29 Answered 11/10, 2020 at 11:19

I have dunno.spec file with the following structure:

Name:                   dunno
Version:                 1.0
...
BuildArch:              x86_64

%description
...
%package common
Summary:                Shared files
BuildArch:              noarch

I suppose that after I run rpmbuild -ba dunno.spec I should get two binary packages:

dunno-1.0.x86_64.rpm
dunno-common-1.0.noarch.rpm

however I get:

dunno-1.0.x86_64.rpm
dunno-common-1.0.x86_64.rpm

If I remove the line BuildArch: x86_64 from the spec, then I get

dunno-1.0.noarch.rpm
dunno-common-1.0.noarch.rpm

How to fix that?

RPM v4.4.2.3.

Micamicaela answered 9/1, 2015 at 14:29 Comment(4)

Good question. If that didn't work I'm not sure you can do it. Though it looks like it is possible in newer versions of RPM than what CentOS 5 has. – Formation 9/1, 2015 at 14:43

@EtanReisner: Could you please share the link to e.g. "what's new" which describes in what RPM version that feature has been implemented? – Micamicaela 9/1, 2015 at 18:37

I don't know. I mentioned that only because the CentOS 6 glib2.spec has a noarch -doc package in it. This seems to be the first tagged version of the Fedora specfile that has that. So somewhere between the CentOS 5 4.4.2.3 and whatever F18 has. Which looks like 4.10.3.1. But that's a huge range and it might have been anywhere in there. – Formation 9/1, 2015 at 18:46

Yes, indeed glib2 package has several flavours in repo. Hopefully this feature was not introduced by a patch (there are more then 10, but all seem to be unrelated). It seems that the only solution for v4.4 is to run rmpbuild twice. – Micamicaela 9/1, 2015 at 19:14

Split the build into 2 packages, one x86_64, the other noarch.

You can do 2 builds from a single spec using %ifarch logic (but its usually easier/cleaner to use 2 spec files even if annoying).

It also hurts nothing to include platform-independent content in an x86_64 sub-package instead of a noarch sub-package.

Goines answered 9/1, 2015 at 14:59 Comment(5)

In case of splitting I would need to maintain other common fields like Version, Url, License. Also the difficulty is that common staff is installed during the build cycle, so two specs will cause two full build cycles (not good). I can of course trick the build so that "light" build cycle is run, but would be conceptually right? Inclusion does not hurt, but I have hidden part of the story: spec produces 3 platform-dependent binary packages, all of them depending on shared platform-independent staff (e.g. settings). – Micamicaela 9/1, 2015 at 18:47

And how %ifarch can help? For example, if I add %ifarch noarch then again I would need to run rpmbuild twice (rpmbuild --target=x86_64 and rpmbuild --target=noarch). – Micamicaela 9/1, 2015 at 18:50

I'd just use all x86_64 sub-packages instead of attempting a noarch sub-package. Lots of x86_64 packages have only noarch content. – Goines 9/1, 2015 at 18:51

Yes %ifarch would need to be built twice, once for x86_64, once for noarch. But Version: etc would be identical and simple to maintain. – Goines 9/1, 2015 at 18:53

Thanks for comments. I think it would be reasonable for me to give up and have .x86_64 for all packages. – Micamicaela 9/1, 2015 at 19:6

You could run the rpmbuild as this rpmbuild --target=x86_64,noarch ... then rpmbuild will build the package two pass for each arch.

Xanthin answered 17/10, 2016 at 7:20 Comment(0)

you should make dunno-common a subpackage

your spec should look like this

Name:                   dunno
Version:                 1.0
# next line is not needed
BuildArch:              x86_64

%package common
BuildArch:              noarch
Summary: ...
%description common
%files 
# ...

%files common
# ...

Gametophyte answered 11/10, 2020 at 11:19 Comment(0)

Recommended topics

Hot tags