Lock packages version with Yocto
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
asked Nov 14 '18 at 8:55
gabblagabbla
14918
add a comment |
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
asked Nov 14 '18 at 8:55
gabblagabbla
14918
add a comment |
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
asked Nov 14 '18 at 8:55
gabblagabbla
14918
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
yocto bitbake
asked Nov 14 '18 at 8:55
gabblagabbla
14918
asked Nov 14 '18 at 8:55
gabblagabbla
14918
edited Nov 14 '18 at 13:05
gabbla
asked Nov 14 '18 at 8:55
gabblagabbla
14918
asked Nov 14 '18 at 8:55
gabblagabbla
14918
asked Nov 14 '18 at 8:55
gabblagabbla
14918
14918
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
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 adistro.incwith 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 commonSSTATE_DIRin yourconf/local.conf
– Parthiban
Nov 14 '18 at 9:56
yes, that was the point, I will maintain adistro.incthat is easier to keep under version control and provide it to any distro that need it. AboutSSTATE_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
|
show 2 more comments
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
);
);
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%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
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.
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
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 adistro.incwith 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 commonSSTATE_DIRin yourconf/local.conf
– Parthiban
Nov 14 '18 at 9:56
yes, that was the point, I will maintain adistro.incthat is easier to keep under version control and provide it to any distro that need it. AboutSSTATE_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
|
show 2 more comments
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.
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
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 adistro.incwith 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 commonSSTATE_DIRin yourconf/local.conf
– Parthiban
Nov 14 '18 at 9:56
yes, that was the point, I will maintain adistro.incthat is easier to keep under version control and provide it to any distro that need it. AboutSSTATE_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
|
show 2 more comments
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.
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
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.
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
answered Nov 14 '18 at 9:43
ParthibanParthiban
1,3842716
1,3842716
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 adistro.incwith 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 commonSSTATE_DIRin yourconf/local.conf
– Parthiban
Nov 14 '18 at 9:56
yes, that was the point, I will maintain adistro.incthat is easier to keep under version control and provide it to any distro that need it. AboutSSTATE_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
|
show 2 more comments
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 adistro.incwith 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 commonSSTATE_DIRin yourconf/local.conf
– Parthiban
Nov 14 '18 at 9:56
yes, that was the point, I will maintain adistro.incthat is easier to keep under version control and provide it to any distro that need it. AboutSSTATE_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
|
show 2 more comments
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.
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%2fstackoverflow.com%2fquestions%2f53296247%2flock-packages-version-with-yocto%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
