How to configure rpmbuild to forbid installing 32 bit package in 64 bit systems?

Clash Royale CLAN TAG#URR8PPP
I'm packaging software in RPM and distributing it in different packages by architecture (32bit or 64bit).
Some libraries of my 32bit package have binaries that cannot be executed in 64bit systems (unless some additional libraries installed).
I've used file command to detect the interpreter needed to execute those binaries, and then added the required libraries as package's dependencies. This only solves a part of the problem, since then other required libraries may collide with the 64bit version installed on end-user's host.
So for sake of simplicity, I would like to know if there is a way to configure rpmbuild to forbid installing 32bit package in 64bit systems (in the same way that 32bit systems doesn't allow to install 64bit packages).
There is any rpmbuild option or .spec value available for that?
rpm 64bit 32bit rpmbuild cpu-architecture
add a comment |
I'm packaging software in RPM and distributing it in different packages by architecture (32bit or 64bit).
Some libraries of my 32bit package have binaries that cannot be executed in 64bit systems (unless some additional libraries installed).
I've used file command to detect the interpreter needed to execute those binaries, and then added the required libraries as package's dependencies. This only solves a part of the problem, since then other required libraries may collide with the 64bit version installed on end-user's host.
So for sake of simplicity, I would like to know if there is a way to configure rpmbuild to forbid installing 32bit package in 64bit systems (in the same way that 32bit systems doesn't allow to install 64bit packages).
There is any rpmbuild option or .spec value available for that?
rpm 64bit 32bit rpmbuild cpu-architecture
add a comment |
I'm packaging software in RPM and distributing it in different packages by architecture (32bit or 64bit).
Some libraries of my 32bit package have binaries that cannot be executed in 64bit systems (unless some additional libraries installed).
I've used file command to detect the interpreter needed to execute those binaries, and then added the required libraries as package's dependencies. This only solves a part of the problem, since then other required libraries may collide with the 64bit version installed on end-user's host.
So for sake of simplicity, I would like to know if there is a way to configure rpmbuild to forbid installing 32bit package in 64bit systems (in the same way that 32bit systems doesn't allow to install 64bit packages).
There is any rpmbuild option or .spec value available for that?
rpm 64bit 32bit rpmbuild cpu-architecture
I'm packaging software in RPM and distributing it in different packages by architecture (32bit or 64bit).
Some libraries of my 32bit package have binaries that cannot be executed in 64bit systems (unless some additional libraries installed).
I've used file command to detect the interpreter needed to execute those binaries, and then added the required libraries as package's dependencies. This only solves a part of the problem, since then other required libraries may collide with the 64bit version installed on end-user's host.
So for sake of simplicity, I would like to know if there is a way to configure rpmbuild to forbid installing 32bit package in 64bit systems (in the same way that 32bit systems doesn't allow to install 64bit packages).
There is any rpmbuild option or .spec value available for that?
rpm 64bit 32bit rpmbuild cpu-architecture
rpm 64bit 32bit rpmbuild cpu-architecture
asked Feb 19 at 11:55
Alejandro S.Alejandro S.
12
12
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
you don't need to do some kind of workaround for that. By default your rpms are built for the architecture you are building on. When building on 64bit system, your built rpms will be named package-version-release.x86_64.rpm ; whence only installable on 64bit systems.
rpmbuild also automatically determines most of your dependencies automatically (unless you use Autoreqprov=no inside your spec file). So when packaging a 32bit application; rpmbuild should normally create the correct requirements (like libc 32bit etc...).
When building a 32bit application and packaging this on a 64bit machine, the only thing you might want to do is force the resulting package to be of i586 architecture, which you can do in the spec file using
BuildArch: i586
Thanks for the answer! I build packages in a 64bit system and I useAutoreqprov=noto tackle manually package's dependencies. I also runrpmbuildwith--target i386to build 32bit packages (and also modifyBuildArch: i386to ensure the change). So, there is no other way to achieve what I want than not usingAutoreqprov=no?
– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT useAutoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you
– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to useAutoreqprov=noto avoidrpmbuildto scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)
– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501573%2fhow-to-configure-rpmbuild-to-forbid-installing-32-bit-package-in-64-bit-systems%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
you don't need to do some kind of workaround for that. By default your rpms are built for the architecture you are building on. When building on 64bit system, your built rpms will be named package-version-release.x86_64.rpm ; whence only installable on 64bit systems.
rpmbuild also automatically determines most of your dependencies automatically (unless you use Autoreqprov=no inside your spec file). So when packaging a 32bit application; rpmbuild should normally create the correct requirements (like libc 32bit etc...).
When building a 32bit application and packaging this on a 64bit machine, the only thing you might want to do is force the resulting package to be of i586 architecture, which you can do in the spec file using
BuildArch: i586
Thanks for the answer! I build packages in a 64bit system and I useAutoreqprov=noto tackle manually package's dependencies. I also runrpmbuildwith--target i386to build 32bit packages (and also modifyBuildArch: i386to ensure the change). So, there is no other way to achieve what I want than not usingAutoreqprov=no?
– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT useAutoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you
– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to useAutoreqprov=noto avoidrpmbuildto scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)
– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
add a comment |
you don't need to do some kind of workaround for that. By default your rpms are built for the architecture you are building on. When building on 64bit system, your built rpms will be named package-version-release.x86_64.rpm ; whence only installable on 64bit systems.
rpmbuild also automatically determines most of your dependencies automatically (unless you use Autoreqprov=no inside your spec file). So when packaging a 32bit application; rpmbuild should normally create the correct requirements (like libc 32bit etc...).
When building a 32bit application and packaging this on a 64bit machine, the only thing you might want to do is force the resulting package to be of i586 architecture, which you can do in the spec file using
BuildArch: i586
Thanks for the answer! I build packages in a 64bit system and I useAutoreqprov=noto tackle manually package's dependencies. I also runrpmbuildwith--target i386to build 32bit packages (and also modifyBuildArch: i386to ensure the change). So, there is no other way to achieve what I want than not usingAutoreqprov=no?
– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT useAutoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you
– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to useAutoreqprov=noto avoidrpmbuildto scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)
– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
add a comment |
you don't need to do some kind of workaround for that. By default your rpms are built for the architecture you are building on. When building on 64bit system, your built rpms will be named package-version-release.x86_64.rpm ; whence only installable on 64bit systems.
rpmbuild also automatically determines most of your dependencies automatically (unless you use Autoreqprov=no inside your spec file). So when packaging a 32bit application; rpmbuild should normally create the correct requirements (like libc 32bit etc...).
When building a 32bit application and packaging this on a 64bit machine, the only thing you might want to do is force the resulting package to be of i586 architecture, which you can do in the spec file using
BuildArch: i586
you don't need to do some kind of workaround for that. By default your rpms are built for the architecture you are building on. When building on 64bit system, your built rpms will be named package-version-release.x86_64.rpm ; whence only installable on 64bit systems.
rpmbuild also automatically determines most of your dependencies automatically (unless you use Autoreqprov=no inside your spec file). So when packaging a 32bit application; rpmbuild should normally create the correct requirements (like libc 32bit etc...).
When building a 32bit application and packaging this on a 64bit machine, the only thing you might want to do is force the resulting package to be of i586 architecture, which you can do in the spec file using
BuildArch: i586
answered Feb 19 at 12:29
Chris MaesChris Maes
1,09911018
1,09911018
Thanks for the answer! I build packages in a 64bit system and I useAutoreqprov=noto tackle manually package's dependencies. I also runrpmbuildwith--target i386to build 32bit packages (and also modifyBuildArch: i386to ensure the change). So, there is no other way to achieve what I want than not usingAutoreqprov=no?
– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT useAutoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you
– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to useAutoreqprov=noto avoidrpmbuildto scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)
– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
add a comment |
Thanks for the answer! I build packages in a 64bit system and I useAutoreqprov=noto tackle manually package's dependencies. I also runrpmbuildwith--target i386to build 32bit packages (and also modifyBuildArch: i386to ensure the change). So, there is no other way to achieve what I want than not usingAutoreqprov=no?
– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT useAutoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you
– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to useAutoreqprov=noto avoidrpmbuildto scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)
– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
Thanks for the answer! I build packages in a 64bit system and I use
Autoreqprov=no to tackle manually package's dependencies. I also run rpmbuild with --target i386 to build 32bit packages (and also modify BuildArch: i386 to ensure the change). So, there is no other way to achieve what I want than not using Autoreqprov=no?– Alejandro S.
Feb 19 at 12:51
Thanks for the answer! I build packages in a 64bit system and I use
Autoreqprov=no to tackle manually package's dependencies. I also run rpmbuild with --target i386 to build 32bit packages (and also modify BuildArch: i386 to ensure the change). So, there is no other way to achieve what I want than not using Autoreqprov=no?– Alejandro S.
Feb 19 at 12:51
no, I'm saying you should NOT use
Autoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you– Chris Maes
Feb 19 at 15:59
no, I'm saying you should NOT use
Autoreqprov=no. leaving autoreqprov enabled, rpmbuild will manage the dependencies himself. As you said the 32bit version could be installed if the correct dependencies are present. Well autoreqprov should add these dependencies for you– Chris Maes
Feb 19 at 15:59
I understood what you meant. What I'm saying it's that I need to use
Autoreqprov=no to avoid rpmbuild to scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)– Alejandro S.
Feb 19 at 16:26
I understood what you meant. What I'm saying it's that I need to use
Autoreqprov=no to avoid rpmbuild to scan some dependencies, so I need to use this value. That's why I'm looking for a way (if exists) to forbid the installation of my 32bit package on 64bit systems. If not, then I'll look for another approach. Thanks anyway! ;)– Alejandro S.
Feb 19 at 16:26
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
ok. If you are always building a 64bit AND a 32bit version together, then you don't really need to forbid this. each package manager (yum, zypper) will automatically select 64bit if possible...
– Chris Maes
Feb 19 at 16:38
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
That won't work neither since the packages will only be available via web browser. Hence, there isn't any repository involved.
– Alejandro S.
Feb 19 at 16:48
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501573%2fhow-to-configure-rpmbuild-to-forbid-installing-32-bit-package-in-64-bit-systems%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown