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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












0















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?










share|improve this question


























    0















    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?










    share|improve this question
























      0












      0








      0








      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?










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Feb 19 at 11:55









      Alejandro S.Alejandro S.

      12




      12




















          1 Answer
          1






          active

          oldest

          votes


















          0














          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





          share|improve this answer























          • 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











          • 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











          • 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










          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
          );



          );













          draft saved

          draft discarded


















          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









          0














          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





          share|improve this answer























          • 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











          • 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











          • 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















          0














          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





          share|improve this answer























          • 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











          • 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











          • 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













          0












          0








          0







          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





          share|improve this answer













          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






          share|improve this answer












          share|improve this answer



          share|improve this answer










          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 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











          • 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











          • 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












          • 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











          • 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

















          draft saved

          draft discarded
















































          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.




          draft saved


          draft discarded














          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





















































          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






          Popular posts from this blog

          Peggy Mitchell

          Palaiologos

          The Forum (Inglewood, California)