Lock packages version with Yocto










0















we are about to set up a production build server to maintain a embedded linux product. I know that I can specify a package version with PREFERRED_VERSION_<package> inside the recipe, but this may take a lot of time to lock every single tool in the image (i.e. grep, strace, ecc). This will be useful in case we need to rebuild the server (we could backup the whole server, but this wont be traced. Even commit everything to a git repo seems to be not so clever, correct me if I'm wrong).



Is there a way to get something like package-lock.json or an image footprint?



EDIT



What I'd like to achieve is a list of



PREFERRED_VERSION_<package0> = "xxx"
...
PREFERRED_VERSION_<packageN> = "xxx"


that I can use to replicate the image on a clear system (without any cached file). It seems that there is no such command to do that directly, instead it's possible to get a list of image packages and version by



bitbake <image> -s


and with a simple script generates what I'm looking for.










share|improve this question




























    0















    we are about to set up a production build server to maintain a embedded linux product. I know that I can specify a package version with PREFERRED_VERSION_<package> inside the recipe, but this may take a lot of time to lock every single tool in the image (i.e. grep, strace, ecc). This will be useful in case we need to rebuild the server (we could backup the whole server, but this wont be traced. Even commit everything to a git repo seems to be not so clever, correct me if I'm wrong).



    Is there a way to get something like package-lock.json or an image footprint?



    EDIT



    What I'd like to achieve is a list of



    PREFERRED_VERSION_<package0> = "xxx"
    ...
    PREFERRED_VERSION_<packageN> = "xxx"


    that I can use to replicate the image on a clear system (without any cached file). It seems that there is no such command to do that directly, instead it's possible to get a list of image packages and version by



    bitbake <image> -s


    and with a simple script generates what I'm looking for.










    share|improve this question


























      0












      0








      0








      we are about to set up a production build server to maintain a embedded linux product. I know that I can specify a package version with PREFERRED_VERSION_<package> inside the recipe, but this may take a lot of time to lock every single tool in the image (i.e. grep, strace, ecc). This will be useful in case we need to rebuild the server (we could backup the whole server, but this wont be traced. Even commit everything to a git repo seems to be not so clever, correct me if I'm wrong).



      Is there a way to get something like package-lock.json or an image footprint?



      EDIT



      What I'd like to achieve is a list of



      PREFERRED_VERSION_<package0> = "xxx"
      ...
      PREFERRED_VERSION_<packageN> = "xxx"


      that I can use to replicate the image on a clear system (without any cached file). It seems that there is no such command to do that directly, instead it's possible to get a list of image packages and version by



      bitbake <image> -s


      and with a simple script generates what I'm looking for.










      share|improve this question
















      we are about to set up a production build server to maintain a embedded linux product. I know that I can specify a package version with PREFERRED_VERSION_<package> inside the recipe, but this may take a lot of time to lock every single tool in the image (i.e. grep, strace, ecc). This will be useful in case we need to rebuild the server (we could backup the whole server, but this wont be traced. Even commit everything to a git repo seems to be not so clever, correct me if I'm wrong).



      Is there a way to get something like package-lock.json or an image footprint?



      EDIT



      What I'd like to achieve is a list of



      PREFERRED_VERSION_<package0> = "xxx"
      ...
      PREFERRED_VERSION_<packageN> = "xxx"


      that I can use to replicate the image on a clear system (without any cached file). It seems that there is no such command to do that directly, instead it's possible to get a list of image packages and version by



      bitbake <image> -s


      and with a simple script generates what I'm looking for.







      yocto bitbake






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 14 '18 at 13:05







      gabbla

















      asked Nov 14 '18 at 8:55









      gabblagabbla

      14918




      14918






















          1 Answer
          1






          active

          oldest

          votes


















          1














          We have distro configuration, where you can specify all the version preferences. For example, the below samples are copied from poky.conf and bleeding.conf



          PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
          PREFERRED_VERSION_glib-2.0-native ?= "2.17.4"
          PREFERRED_VERSION_atk ?= "1.22.0"
          PREFERRED_VERSION_pango ?= "1.21.2"
          PREFERRED_VERSION_gtk+ ?= "2.13.3"

          require conf/distro/include/poky-floating-revisions.inc
          require conf/distro/poky.conf

          DISTRO = "poky-bleeding"
          DISTROOVERRIDES = "poky"


          So you can define all the SRCREV and PREFERRED_VERSION in distro configuration or write a separate distro.inc and add it using require. And to use this for compilation, you can define,



          DISTRO ?= "poky-bleeding"


          in your conf/local.conf. This way you can control all the version and SRCREV for git based recipes at place.






          share|improve this answer























          • Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

            – gabbla
            Nov 14 '18 at 9:52











          • @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

            – Parthiban
            Nov 14 '18 at 9:54











          • @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

            – Parthiban
            Nov 14 '18 at 9:56











          • yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

            – gabbla
            Nov 14 '18 at 10:15











          • @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

            – Parthiban
            Nov 14 '18 at 10:19










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          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: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          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%2fstackoverflow.com%2fquestions%2f53296247%2flock-packages-version-with-yocto%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









          1














          We have distro configuration, where you can specify all the version preferences. For example, the below samples are copied from poky.conf and bleeding.conf



          PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
          PREFERRED_VERSION_glib-2.0-native ?= "2.17.4"
          PREFERRED_VERSION_atk ?= "1.22.0"
          PREFERRED_VERSION_pango ?= "1.21.2"
          PREFERRED_VERSION_gtk+ ?= "2.13.3"

          require conf/distro/include/poky-floating-revisions.inc
          require conf/distro/poky.conf

          DISTRO = "poky-bleeding"
          DISTROOVERRIDES = "poky"


          So you can define all the SRCREV and PREFERRED_VERSION in distro configuration or write a separate distro.inc and add it using require. And to use this for compilation, you can define,



          DISTRO ?= "poky-bleeding"


          in your conf/local.conf. This way you can control all the version and SRCREV for git based recipes at place.






          share|improve this answer























          • Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

            – gabbla
            Nov 14 '18 at 9:52











          • @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

            – Parthiban
            Nov 14 '18 at 9:54











          • @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

            – Parthiban
            Nov 14 '18 at 9:56











          • yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

            – gabbla
            Nov 14 '18 at 10:15











          • @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

            – Parthiban
            Nov 14 '18 at 10:19















          1














          We have distro configuration, where you can specify all the version preferences. For example, the below samples are copied from poky.conf and bleeding.conf



          PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
          PREFERRED_VERSION_glib-2.0-native ?= "2.17.4"
          PREFERRED_VERSION_atk ?= "1.22.0"
          PREFERRED_VERSION_pango ?= "1.21.2"
          PREFERRED_VERSION_gtk+ ?= "2.13.3"

          require conf/distro/include/poky-floating-revisions.inc
          require conf/distro/poky.conf

          DISTRO = "poky-bleeding"
          DISTROOVERRIDES = "poky"


          So you can define all the SRCREV and PREFERRED_VERSION in distro configuration or write a separate distro.inc and add it using require. And to use this for compilation, you can define,



          DISTRO ?= "poky-bleeding"


          in your conf/local.conf. This way you can control all the version and SRCREV for git based recipes at place.






          share|improve this answer























          • Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

            – gabbla
            Nov 14 '18 at 9:52











          • @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

            – Parthiban
            Nov 14 '18 at 9:54











          • @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

            – Parthiban
            Nov 14 '18 at 9:56











          • yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

            – gabbla
            Nov 14 '18 at 10:15











          • @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

            – Parthiban
            Nov 14 '18 at 10:19













          1












          1








          1







          We have distro configuration, where you can specify all the version preferences. For example, the below samples are copied from poky.conf and bleeding.conf



          PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
          PREFERRED_VERSION_glib-2.0-native ?= "2.17.4"
          PREFERRED_VERSION_atk ?= "1.22.0"
          PREFERRED_VERSION_pango ?= "1.21.2"
          PREFERRED_VERSION_gtk+ ?= "2.13.3"

          require conf/distro/include/poky-floating-revisions.inc
          require conf/distro/poky.conf

          DISTRO = "poky-bleeding"
          DISTROOVERRIDES = "poky"


          So you can define all the SRCREV and PREFERRED_VERSION in distro configuration or write a separate distro.inc and add it using require. And to use this for compilation, you can define,



          DISTRO ?= "poky-bleeding"


          in your conf/local.conf. This way you can control all the version and SRCREV for git based recipes at place.






          share|improve this answer













          We have distro configuration, where you can specify all the version preferences. For example, the below samples are copied from poky.conf and bleeding.conf



          PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
          PREFERRED_VERSION_glib-2.0-native ?= "2.17.4"
          PREFERRED_VERSION_atk ?= "1.22.0"
          PREFERRED_VERSION_pango ?= "1.21.2"
          PREFERRED_VERSION_gtk+ ?= "2.13.3"

          require conf/distro/include/poky-floating-revisions.inc
          require conf/distro/poky.conf

          DISTRO = "poky-bleeding"
          DISTROOVERRIDES = "poky"


          So you can define all the SRCREV and PREFERRED_VERSION in distro configuration or write a separate distro.inc and add it using require. And to use this for compilation, you can define,



          DISTRO ?= "poky-bleeding"


          in your conf/local.conf. This way you can control all the version and SRCREV for git based recipes at place.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 14 '18 at 9:43









          ParthibanParthiban

          1,3842717




          1,3842717












          • Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

            – gabbla
            Nov 14 '18 at 9:52











          • @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

            – Parthiban
            Nov 14 '18 at 9:54











          • @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

            – Parthiban
            Nov 14 '18 at 9:56











          • yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

            – gabbla
            Nov 14 '18 at 10:15











          • @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

            – Parthiban
            Nov 14 '18 at 10:19

















          • Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

            – gabbla
            Nov 14 '18 at 9:52











          • @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

            – Parthiban
            Nov 14 '18 at 9:54











          • @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

            – Parthiban
            Nov 14 '18 at 9:56











          • yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

            – gabbla
            Nov 14 '18 at 10:15











          • @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

            – Parthiban
            Nov 14 '18 at 10:19
















          Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

          – gabbla
          Nov 14 '18 at 9:52





          Alright, but what if I build an image with latest revision and I want a snapshot of that revision, so the image can be duplicated even if I start from scratch (with the needed meta layer already imported)? If I get it, in your solution I have to gather all the version by hand (or script) and then write a distro.inc with them. am I right?

          – gabbla
          Nov 14 '18 at 9:52













          @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

          – Parthiban
          Nov 14 '18 at 9:54





          @gabbla: Yes you need to maintain the versions someway or other. If I understand correctly, you question is about to maintain the needed version all at one place.

          – Parthiban
          Nov 14 '18 at 9:54













          @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

          – Parthiban
          Nov 14 '18 at 9:56





          @gabbla: If you build with latest revision, then yocto stores all the information as cache and when you re-build the same version again into new scratch build, yocto can use the sstate cache to copy the binary instead of building it from source. For that you need specify common SSTATE_DIR in your conf/local.conf

          – Parthiban
          Nov 14 '18 at 9:56













          yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

          – gabbla
          Nov 14 '18 at 10:15





          yes, that was the point, I will maintain a distro.inc that is easier to keep under version control and provide it to any distro that need it. About SSTATE_DIR, I won't depend on sources pre-downloaded, because there might be the case where I don't have that cache and checking out the latest version may result in a newer package, then in a different image

          – gabbla
          Nov 14 '18 at 10:15













          @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

          – Parthiban
          Nov 14 '18 at 10:19





          @gabbla: So what's you question here? If you switch to latest version, you will be downloaded with new source version and compilation will be done from source. That's way it should work. When you want to re-do the same version, it can copy from cache. But yocto relies on version, when you change it, it will add that to task queue and re-compile it.

          – Parthiban
          Nov 14 '18 at 10:19



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • 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%2fstackoverflow.com%2fquestions%2f53296247%2flock-packages-version-with-yocto%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

          Use pre created SQLite database for Android project in kotlin

          Darth Vader #20

          Ondo