can pkg_{pre, post}rm functions be run at all for image creation?

DISCUSSION Robert P. J. Day 4 participants 10 messages Aug 2, 2014 – Aug 4, 2014

Share & tools

Robert P. J. Day

author

2014-08-02 16:34 UTC #0 lore raw

followup to earlier note, is it true that the pkg_prerm and
pkg_postrm functions cannot be run at all during image creation, but only on the actual running target? this would seem reasonable as it doesn't seem to make sense to be running any sort of removal code during image creation.

(i'm assuming that it is never the case that any sort of package
removal is done during image creation, and that the creation process will install *only* those packages that should be part of the final image, is that correct?)

however, if the above is correct, then it would make sense that all,
say, pkg_prerm() functions would never be written with respect to the variable ${D}, which would be relevant only during image creation. but i can see things like this in sysklogd.inc:

pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
        if test "$1" = "upgrade" -o "$1" = "remove"; then
                /etc/init.d/syslog stop
        fi
        fi
}

so what does that mean?

rday

Signature · 7 lines

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Khem Raj

2014-08-02 19:41 UTC #1 lore raw

Quoted 6 lines · Robert P. J. Day

say, pkg_prerm() functions would never be written with respect to the variable ${D}, which would be relevant only during image creation. but i can see things like this in sysklogd.inc:
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then

note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.

Robert P. J. Day

author

2014-08-02 19:57 UTC #2 lore raw

Quoted 10 lines · Khem Raj

Quoted 6 lines · Robert P. J. Day
say, pkg_prerm() functions would never be written with respect to the variable ${D}, which would be relevant only during image creation. but i can see things like this in sysklogd.inc:
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.

i still don't understand ... what are the possible values of $D
here, and what would they represent?

rday

Signature · 7 lines

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Khem Raj

2014-08-02 20:06 UTC #3 lore raw

Quoted 7 lines · Robert P. J. Day

Quoted 5 lines · Khem Raj
Quoted 4 lines · Robert P. J. Day
say, pkg_prerm() functions would never be written with respect to the variable ${D}, which would be relevant only during image creation. but i can see things like this in sysklogd.inc:

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.
i still don't understand ... what are the possible values of $D
here, and what would they represent?

At build time it will not be expanded by bitbake like ${D} is. but during image creation it will be. But when doing on-device install of this package $D will be empty. Its a way to differentiate actions during image creation and on-device install/update/remove

-Khem

Robert P. J. Day

author

2014-08-03 06:56 UTC #4 lore raw

Quoted 14 lines · Khem Raj

Quoted 13 lines · Robert P. J. Day
Quoted 10 lines · Khem Raj
Quoted 6 lines · Robert P. J. Day
say, pkg_prerm() functions would never be written with respect to the variable ${D}, which would be relevant only during image creation. but i can see things like this in sysklogd.inc:
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.

Quoted 7 lines

Quoted 2 lines
i still don't understand ... what are the possible values of $D
here, and what would they represent?
At build time it will not be expanded by bitbake like ${D} is. but during image creation it will be. But when doing on-device install of this package $D will be empty. Its a way to differentiate actions during image creation and on-device install/update/remove

but the yocto dev manual states pretty clearly that pkg_prerm and
pkg_postrm functions are *not* used during image creation. so you're saying they are? under what circumstances?

rday

Signature · 7 lines

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Paul Eggleton

2014-08-04 12:37 UTC #5 lore raw

Quoted 4 lines · On Sunday 03 August 2014 02:56:04 Robert P. J. Day wrote:

Quoted 3 lines · Khem Raj
Quoted 2 lines · Robert P. J. Day
Quoted 1 line · Khem Raj
On Sat, Aug 2, 2014 at 9:34 AM, Robert P. J. Day

Quoted 17 lines · <[email protected]> wrote:

Quoted 17 lines
Quoted 16 lines
Quoted 6 lines
Quoted 6 lines
say, pkg_prerm() functions would never be written with respect to the
variable ${D}, which would be relevant only during image creation. but
i can see things like this in sysklogd.inc:
Quoted 7 lines
Quoted 3 lines
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.
i still don't understand ... what are the possible values of $D
here, and what would they represent?

Quoted 8 lines

Quoted 4 lines
At build time it will not be expanded by bitbake like ${D} is. but during image creation it will be. But when doing on-device install of this package $D will be empty. Its a way to differentiate actions during image creation and on-device install/update/remove
but the yocto dev manual states pretty clearly that pkg_prerm and
pkg_postrm functions are *not* used during image creation. so you're saying they are? under what circumstances?

They wouldn't normally be. You could in theory issue some package removal commands as part of postprocessing on the image but I can't see much use for that given we have things like PACKAGE_EXCLUDE now.

Khem was simply correcting your reference to ${D}. I can only imagine the example you gave is just belt-and-braces to make sure it could never be run outside the context of the real target.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Robert P. J. Day

author

2014-08-04 13:42 UTC #6 lore raw

Quoted 28 lines · Paul Eggleton

Quoted 4 lines · On Sunday 03 August 2014 02:56:04 Robert P. J. Day wrote:
Quoted 3 lines · Khem Raj
Quoted 2 lines · Robert P. J. Day
Quoted 1 line · Khem Raj
On Sat, Aug 2, 2014 at 9:34 AM, Robert P. J. Day
Quoted 22 lines · <[email protected]> wrote:
Quoted 21 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
say, pkg_prerm() functions would never be written with respect to the
variable ${D}, which would be relevant only during image creation. but
i can see things like this in sysklogd.inc:
pkg_prerm_${PN} () {
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.
i still don't understand ... what are the possible values of $D
here, and what would they represent?
At build time it will not be expanded by bitbake like ${D} is. but during image creation it will be. But when doing on-device install of this package $D will be empty. Its a way to differentiate actions during image creation and on-device install/update/remove

Quoted 7 lines

Quoted 3 lines
but the yocto dev manual states pretty clearly that pkg_prerm and
pkg_postrm functions are *not* used during image creation. so you're saying they are? under what circumstances?
They wouldn't normally be. You could in theory issue some package removal commands as part of postprocessing on the image but I can't see much use for that given we have things like PACKAGE_EXCLUDE now.

oooooh ... that's still kind of weaselly terminology. :-) i'm not
*trying* to be annoyingly pedantic, but this is just the kind of thing that students tend to ask about, which is why i want to nail the details.

the current docs state that pkg_*rm routines are *not* run during
image creation, and i'm going to accept that. that means that if a pkg_*rm routine *is* written with reference to ${D}, as long as that's run on the target, it won't make a difference. so the references to ${D} in that context don't *hurt*, they're just unnecessary. and potentially confusing, which is why i'm trying to clarify this. (every pkg_*rm routine i've seen, *if* it tests the value of ${D}, bailed if it was set, which makes sense if they should never, ever be invoked at image creation time.)

WRT stuff run at rootfs postprocessing time, sure, you could always
run a package removal command, but clarify this for me -- once you're into rootfs postprocessing, you're running in a "pseudo" environment such that you are *effectively* running inside that rootfs, no? so in that case, all filename references would be full names WRT to the root filesystem -- no references to ${D}. is that correct? or am i just confused?

Quoted 3 lines

Khem was simply correcting your reference to ${D}. I can only imagine the example you gave is just belt-and-braces to make sure it could never be run outside the context of the real target.

fair enough. as it is, it's simply overkill. gotcha.

rday

Signature · 7 lines

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Paul Eggleton

2014-08-04 13:51 UTC #7 lore raw

Quoted 37 lines · On Monday 04 August 2014 09:42:35 Robert P. J. Day wrote:

Quoted 36 lines · Paul Eggleton
Quoted 4 lines · On Sunday 03 August 2014 02:56:04 Robert P. J. Day wrote:
Quoted 3 lines · Khem Raj
Quoted 2 lines · Robert P. J. Day
Quoted 1 line · Khem Raj
On Sat, Aug 2, 2014 at 9:34 AM, Robert P. J. Day
Quoted 28 lines · <[email protected]> wrote:
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
say, pkg_prerm() functions would never be written with respect to
the
variable ${D}, which would be relevant only during image creation.
but
i can see things like this in sysklogd.inc:
pkg_prerm_${PN} () {
        if test "x$D" = "x"; then
note that its not ${D} (bitbake context) but $D which is evaluated in the context when the script is run.
Quoted 9 lines
Quoted 3 lines
i still don't understand ... what are the possible values of $D
here, and what would they represent?
At build time it will not be expanded by bitbake like ${D} is. but during image creation it will be. But when doing on-device install of this package $D will be empty. Its a way to differentiate actions during image creation and on-device install/update/remove
but the yocto dev manual states pretty clearly that pkg_prerm and
pkg_postrm functions are *not* used during image creation. so you're saying they are? under what circumstances?

Quoted 8 lines

Quoted 3 lines
They wouldn't normally be. You could in theory issue some package removal commands as part of postprocessing on the image but I can't see much use for that given we have things like PACKAGE_EXCLUDE now.
oooooh ... that's still kind of weaselly terminology. :-) i'm not
*trying* to be annoyingly pedantic, but this is just the kind of thing that students tend to ask about, which is why i want to nail the details.

Is this pointless right now? Yes. Does it hurt? No.

Quoted 9 lines

the current docs state that pkg_*rm routines are *not* run during
image creation, and i'm going to accept that. that means that if a pkg_*rm routine *is* written with reference to ${D}, as long as that's run on the target, it won't make a difference. so the references to ${D} in that context don't *hurt*, they're just unnecessary. and potentially confusing, which is why i'm trying to clarify this. (every pkg_*rm routine i've seen, *if* it tests the value of ${D}, bailed if it was set, which makes sense if they should never, ever be invoked at image creation time.)

Yes, but when we are talking about preinst/postinst/prerm/postrm, as mentioned before it is $D *not* ${D}. If you use ${D} instead there, you will have problems.

Quoted 7 lines

WRT stuff run at rootfs postprocessing time, sure, you could always
run a package removal command, but clarify this for me -- once you're into rootfs postprocessing, you're running in a "pseudo" environment such that you are *effectively* running inside that rootfs, no? so in that case, all filename references would be full names WRT to the root filesystem -- no references to ${D}. is that correct? or am i just confused?

You are a bit confused yes. do_rootfs may be running under pseudo, but it is not chrooted such that / is the root of the image being constructed; hence why you need to use $D in order to be looking in the right place in both contexts (during constructing the rootfs on the build machine where $D is set, and on the target where $D is not set).

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Richard Purdie

2014-08-04 13:53 UTC #8 lore raw

In reply to Robert P. J. Day

Quoted 5 lines · Robert P. J. Day

oooooh ... that's still kind of weaselly terminology. :-) i'm not
*trying* to be annoyingly pedantic, but this is just the kind of thing that students tend to ask about, which is why i want to nail the details.

Quoted 9 lines

the current docs state that pkg_*rm routines are *not* run during
image creation, and i'm going to accept that. that means that if a pkg_*rm routine *is* written with reference to ${D}, as long as that's run on the target, it won't make a difference. so the references to ${D} in that context don't *hurt*, they're just unnecessary. and potentially confusing, which is why i'm trying to clarify this. (every pkg_*rm routine i've seen, *if* it tests the value of ${D}, bailed if it was set, which makes sense if they should never, ever be invoked at image creation time.)

In the interests of being pedantic since I know you value correctness, they test $D. If they used ${D}, it would get expanded by bitbake at build time which is not what you want.

Quoted 7 lines

WRT stuff run at rootfs postprocessing time, sure, you could always
run a package removal command, but clarify this for me -- once you're into rootfs postprocessing, you're running in a "pseudo" environment such that you are *effectively* running inside that rootfs, no? so in that case, all filename references would be full names WRT to the root filesystem -- no references to ${D}. is that correct? or am i just confused?

Pseudo environment means you can perform operations as root, its not a chroot. You could be in a pseudo chroot of course but our image generation isn't.

Cheers,

Richard

Robert P. J. Day

author

2014-08-04 13:56 UTC #9 lore raw

Quoted 28 lines · Richard Purdie

Quoted 5 lines · Robert P. J. Day
oooooh ... that's still kind of weaselly terminology. :-) i'm not
*trying* to be annoyingly pedantic, but this is just the kind of thing that students tend to ask about, which is why i want to nail the details.
Quoted 9 lines
the current docs state that pkg_*rm routines are *not* run during
image creation, and i'm going to accept that. that means that if a pkg_*rm routine *is* written with reference to ${D}, as long as that's run on the target, it won't make a difference. so the references to ${D} in that context don't *hurt*, they're just unnecessary. and potentially confusing, which is why i'm trying to clarify this. (every pkg_*rm routine i've seen, *if* it tests the value of ${D}, bailed if it was set, which makes sense if they should never, ever be invoked at image creation time.)
In the interests of being pedantic since I know you value correctness, they test $D. If they used ${D}, it would get expanded by bitbake at build time which is not what you want.
Quoted 7 lines
WRT stuff run at rootfs postprocessing time, sure, you could always
run a package removal command, but clarify this for me -- once you're into rootfs postprocessing, you're running in a "pseudo" environment such that you are *effectively* running inside that rootfs, no? so in that case, all filename references would be full names WRT to the root filesystem -- no references to ${D}. is that correct? or am i just confused?

Quoted 3 lines

Pseudo environment means you can perform operations as root, its not a chroot. You could be in a pseudo chroot of course but our image generation isn't.

ok, i think i've got it, thanks, both of you.

rday

Signature · 7 lines

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================