* Per image customizations @ 2016-05-31 16:05 Diego 2016-05-31 23:57 ` Paul Eggleton 0 siblings, 1 reply; 22+ messages in thread From: Diego @ 2016-05-31 16:05 UTC (permalink / raw) To: yocto Hi guys, I've asked this question on IRC, but haven't received complete enough replies, so posting here. I have my own layer with my recipes and customizations. In my layer I have two images, one which is the "regular OS" that runs the product application, and one which is the "flash OS", a minimal ramdisk OS that flashes the disks. I want the two images to have different fstab and inittab files: what is the correct way to do that? I know how to handle machine / arch specific differences, but I don't think there's a way to "dress a package depending on the image it gets included in", right? Should I create my own IMAGE_FEATURE and hack my fstab and inittab when rootfs is created, sort of how the "read-only-rootfs" feature was done? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass?h=fido#n77 Thanks for any help you'll give. Diego ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-05-31 16:05 Per image customizations Diego @ 2016-05-31 23:57 ` Paul Eggleton 2016-06-01 12:25 ` Oleksandr Poznyak 0 siblings, 1 reply; 22+ messages in thread From: Paul Eggleton @ 2016-05-31 23:57 UTC (permalink / raw) To: Diego; +Cc: yocto Hi Diego, On Tue, 31 May 2016 18:05:19 Diego wrote: > I've asked this question on IRC, but haven't received complete enough > replies, so posting here. > > I have my own layer with my recipes and customizations. In my layer I have > two images, one which is the "regular OS" that runs the product > application, and one which is the "flash OS", a minimal ramdisk OS that > flashes the disks. I want the two images to have different fstab and > inittab files: what is the correct way to do that? I know how to handle > machine / arch specific differences, but I don't think there's a way to > "dress a package depending on the image it gets included in", right? > > Should I create my own IMAGE_FEATURE and hack my fstab and inittab when > rootfs is created, sort of how the "read-only-rootfs" feature was done? > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image. > bbclass?h=fido#n77 You can do that, yes. The only other possibility is outright replacing the package providing the file (since you are free to specify whatever packages you want in the image, though you may have to break up packagegroup-core-boot to do it). This only works of course if either there are no dependencies on the package or you can satisfy any dependencies that might exist. It could be that for your "flash OS" image there aren't any, but it depends what it has in it. It may be simpler just to hack it after the fact though. Note that you don't have to add an IMAGE_FEATURES item to do that - you could simply create a shell/python function and add a call to it in ROOTFS_POSTPROCESS_COMMAND. If the changes to the files are substantial you could even supply the alternative files in a separate package and then move them over the top of the original ones in the postprocessing function to save jumping through hoops adding files to the image recipe. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-05-31 23:57 ` Paul Eggleton @ 2016-06-01 12:25 ` Oleksandr Poznyak 2016-06-01 16:15 ` Diego 0 siblings, 1 reply; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-01 12:25 UTC (permalink / raw) To: Paul Eggleton; +Cc: Diego, yocto [-- Attachment #1: Type: text/plain, Size: 2874 bytes --] Don't forget to add your fstab/inittab files into CONFFILES_${PN} cause if the package that includes them will be changed and You'll update it via package system, your POSTPROCESS hacks will be overwritten. Anyway, its better to avoid POSTPROCESS if possible. 1) Create *.bbappend recipe base-files_%s.bbappend in your layer. It appends to poky "base-files" recipe. 2) Create your own "python do_package_prepend" function where you should make your recipe produce two different packages 3) Add them to DEPENDS in your image recipe On Wed, Jun 1, 2016 at 2:57 AM, Paul Eggleton <paul.eggleton@linux.intel.com > wrote: > Hi Diego, > > On Tue, 31 May 2016 18:05:19 Diego wrote: > > I've asked this question on IRC, but haven't received complete enough > > replies, so posting here. > > > > I have my own layer with my recipes and customizations. In my layer I > have > > two images, one which is the "regular OS" that runs the product > > application, and one which is the "flash OS", a minimal ramdisk OS that > > flashes the disks. I want the two images to have different fstab and > > inittab files: what is the correct way to do that? I know how to handle > > machine / arch specific differences, but I don't think there's a way to > > "dress a package depending on the image it gets included in", right? > > > > Should I create my own IMAGE_FEATURE and hack my fstab and inittab when > > rootfs is created, sort of how the "read-only-rootfs" feature was done? > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image > . > > bbclass?h=fido#n77 > > You can do that, yes. The only other possibility is outright replacing the > package providing the file (since you are free to specify whatever packages > you want in the image, though you may have to break up > packagegroup-core-boot > to do it). This only works of course if either there are no dependencies on > the package or you can satisfy any dependencies that might exist. It could > be > that for your "flash OS" image there aren't any, but it depends what it > has in > it. > > It may be simpler just to hack it after the fact though. Note that you > don't > have to add an IMAGE_FEATURES item to do that - you could simply create a > shell/python function and add a call to it in ROOTFS_POSTPROCESS_COMMAND. > If > the changes to the files are substantial you could even supply the > alternative > files in a separate package and then move them over the top of the original > ones in the postprocessing function to save jumping through hoops adding > files > to the image recipe. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > [-- Attachment #2: Type: text/html, Size: 3714 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-01 12:25 ` Oleksandr Poznyak @ 2016-06-01 16:15 ` Diego 2016-06-01 18:57 ` Oleksandr Poznyak 0 siblings, 1 reply; 22+ messages in thread From: Diego @ 2016-06-01 16:15 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, yocto In data mercoledì 1 giugno 2016 15:25:09, Oleksandr Poznyak ha scritto: > Don't forget to add your fstab/inittab files into CONFFILES_${PN} cause if > the package that includes them will be changed and You'll update it via > package system, your POSTPROCESS hacks will be overwritten. > > Anyway, its better to avoid POSTPROCESS if possible. > 1) Create *.bbappend recipe base-files_%s.bbappend in your layer. It > appends to poky "base-files" recipe. > 2) Create your own "python do_package_prepend" function where you should > make your recipe produce two different packages > 3) Add them to DEPENDS in your image recipe > Hi Oleksandr, your approach is really interesting, but I'm unsure how to proceed with step 2) of your list. I've added the following in the bbappend: python do_package_prepend() { d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular ${PN}-fstab-flash") } which creates the two additional packages, but then I'm confused on how to manage the two 'variant' fstab files. The FILES variable doesn't support "source -> destination", so how do I manage the fact that two different files need to go to the same destination path? An easier option would be to remove fstab in the base-files_%s.bbappend, and create 2 different .bb recipes for the 2 fstab files. Thanks anyhow for your help, Diego ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-01 16:15 ` Diego @ 2016-06-01 18:57 ` Oleksandr Poznyak 2016-06-03 13:52 ` Diego 2016-06-06 20:55 ` Edward Wingate 0 siblings, 2 replies; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-01 18:57 UTC (permalink / raw) To: Diego; +Cc: Paul Eggleton, yocto [-- Attachment #1: Type: text/plain, Size: 2978 bytes --] Here is the content of bbappend recipe for base-files recipe: FILESEXTRAPATHS_append := "${THISDIR}/${PN}" SRC_URI += "file://fstab-flash \ file://fstab-regular \ " PACKAGES += " ${PN}-flash ${PN}-regular" CONFFILES_${PN}-flash = "${CONFFILES_${PN}}" CONFFILES_${PN}-regular = "${CONFFILES_${PN}}" pkg_preinst_${PN}-flash = "${pkg_preinst_${PN}}" pkg_preinst_${PN}-regular = "${pkg_preinst_${PN}}" RREPLACES_${PN}-flash = "${PN}" RPROVIDES_${PN}-flash = "${PN}" RCONFLICTS_${PN}-flash = "${PN}" RREPLACES_${PN}-regular = "${PN}" RPROVIDES_${PN}-regular = "${PN}" RCONFLICTS_${PN}-regular = "${PN}" python populate_packages_prepend() { import shutil packages = ("${PN}-flash", "${PN}-regular") for package in packages: # copy ${PN} content to packages shutil.copytree("${PKGD}", "${PKGDEST}/%s" % package, symlinks=True) # replace fstab if package == "${PN}-flash": shutil.copy("${WORKDIR}/fstab-flash", "${PKGDEST}/${PN}-flash/etc/fstab") else: shutil.copy("${WORKDIR}/fstab-regular", "${PKGDEST}/${PN}-regular/etc/fstab") } This will produce two separate packages that will replace base-files package. Moreover, this trick allows You to modify base-files package separately for flash-OS and regular-OS in other recipes add packages like this: base-files-flash or base-files-regular Thanks, Oleksandr Poznyak! On Wed, Jun 1, 2016 at 7:15 PM, Diego <diego.ml@zoho.com> wrote: > In data mercoledì 1 giugno 2016 15:25:09, Oleksandr Poznyak ha scritto: > > Don't forget to add your fstab/inittab files into CONFFILES_${PN} cause > if > > the package that includes them will be changed and You'll update it via > > package system, your POSTPROCESS hacks will be overwritten. > > > > Anyway, its better to avoid POSTPROCESS if possible. > > 1) Create *.bbappend recipe base-files_%s.bbappend in your layer. It > > appends to poky "base-files" recipe. > > 2) Create your own "python do_package_prepend" function where you should > > make your recipe produce two different packages > > 3) Add them to DEPENDS in your image recipe > > > > Hi Oleksandr, > > your approach is really interesting, but I'm unsure how to proceed with > step > 2) of your list. > > I've added the following in the bbappend: > > python do_package_prepend() { > d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular > ${PN}-fstab-flash") > } > > which creates the two additional packages, but then I'm confused on how to > manage the two 'variant' fstab files. The FILES variable doesn't support > "source -> destination", so how do I manage the fact that two different > files > need to go to the same destination path? > > An easier option would be to remove fstab in the base-files_%s.bbappend, > and > create 2 different .bb recipes for the 2 fstab files. > > Thanks anyhow for your help, > Diego > > [-- Attachment #2: Type: text/html, Size: 3933 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-01 18:57 ` Oleksandr Poznyak @ 2016-06-03 13:52 ` Diego 2016-06-03 17:56 ` Oleksandr Poznyak 2016-06-06 20:55 ` Edward Wingate 1 sibling, 1 reply; 22+ messages in thread From: Diego @ 2016-06-03 13:52 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, yocto Hi Oleksandr, In data mercoledì 1 giugno 2016 21:57:32, Oleksandr Poznyak ha scritto: > Here is the content of bbappend recipe for base-files recipe: > > FILESEXTRAPATHS_append := "${THISDIR}/${PN}" > > SRC_URI += "file://fstab-flash \ > file://fstab-regular \ > " > > PACKAGES += " ${PN}-flash ${PN}-regular" > CONFFILES_${PN}-flash = "${CONFFILES_${PN}}" > CONFFILES_${PN}-regular = "${CONFFILES_${PN}}" > > pkg_preinst_${PN}-flash = "${pkg_preinst_${PN}}" > pkg_preinst_${PN}-regular = "${pkg_preinst_${PN}}" > > RREPLACES_${PN}-flash = "${PN}" > RPROVIDES_${PN}-flash = "${PN}" > RCONFLICTS_${PN}-flash = "${PN}" > > RREPLACES_${PN}-regular = "${PN}" > RPROVIDES_${PN}-regular = "${PN}" > RCONFLICTS_${PN}-regular = "${PN}" > > python populate_packages_prepend() { > import shutil > > packages = ("${PN}-flash", "${PN}-regular") > for package in packages: > # copy ${PN} content to packages > shutil.copytree("${PKGD}", "${PKGDEST}/%s" % package, symlinks=True) > # replace fstab > if package == "${PN}-flash": > shutil.copy("${WORKDIR}/fstab-flash", > "${PKGDEST}/${PN}-flash/etc/fstab") > else: > shutil.copy("${WORKDIR}/fstab-regular", > "${PKGDEST}/${PN}-regular/etc/fstab") > } > > > This will produce two separate packages that will replace base-files > package. > Moreover, this trick allows You to modify base-files package separately for > flash-OS and regular-OS > This is very useful, thank you. With this code I'm able to have two different fstab files under packages-split: ./packages-split/base-files-regular/etc/fstab ./packages-split/base-files-flash/etc/fstab Regardless of that though, the resulting rpm packages for "base-files-regular" and "base-files-flash" have the original fstab as in "base-files", which is different to both the fstabs in packages-split mentioned above. I'm looking at what might be causing this, but any idea is welcome. Thanks, Diego ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-03 13:52 ` Diego @ 2016-06-03 17:56 ` Oleksandr Poznyak 2016-06-06 13:27 ` Diego 0 siblings, 1 reply; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-03 17:56 UTC (permalink / raw) To: Diego; +Cc: Paul Eggleton, yocto [-- Attachment #1: Type: text/plain, Size: 2461 bytes --] I found that that’s an issue with rpm packages. I didn't expect there might be some issue with rpm. If you really don't care which package management system to use, switch to deb: PACKAGE_CLASSES = "package_deb" On Fri, Jun 3, 2016 at 4:52 PM, Diego <diego.ml@zoho.com> wrote: > Hi Oleksandr, > > In data mercoledì 1 giugno 2016 21:57:32, Oleksandr Poznyak ha scritto: > > Here is the content of bbappend recipe for base-files recipe: > > > > FILESEXTRAPATHS_append := "${THISDIR}/${PN}" > > > > SRC_URI += "file://fstab-flash \ > > file://fstab-regular \ > > " > > > > PACKAGES += " ${PN}-flash ${PN}-regular" > > CONFFILES_${PN}-flash = "${CONFFILES_${PN}}" > > CONFFILES_${PN}-regular = "${CONFFILES_${PN}}" > > > > pkg_preinst_${PN}-flash = "${pkg_preinst_${PN}}" > > pkg_preinst_${PN}-regular = "${pkg_preinst_${PN}}" > > > > RREPLACES_${PN}-flash = "${PN}" > > RPROVIDES_${PN}-flash = "${PN}" > > RCONFLICTS_${PN}-flash = "${PN}" > > > > RREPLACES_${PN}-regular = "${PN}" > > RPROVIDES_${PN}-regular = "${PN}" > > RCONFLICTS_${PN}-regular = "${PN}" > > > > python populate_packages_prepend() { > > import shutil > > > > packages = ("${PN}-flash", "${PN}-regular") > > for package in packages: > > # copy ${PN} content to packages > > shutil.copytree("${PKGD}", "${PKGDEST}/%s" % package, > symlinks=True) > > # replace fstab > > if package == "${PN}-flash": > > shutil.copy("${WORKDIR}/fstab-flash", > > "${PKGDEST}/${PN}-flash/etc/fstab") > > else: > > shutil.copy("${WORKDIR}/fstab-regular", > > "${PKGDEST}/${PN}-regular/etc/fstab") > > } > > > > > > This will produce two separate packages that will replace base-files > > package. > > Moreover, this trick allows You to modify base-files package separately > for > > flash-OS and regular-OS > > > > This is very useful, thank you. With this code I'm able to have two > different > fstab files under packages-split: > ./packages-split/base-files-regular/etc/fstab > ./packages-split/base-files-flash/etc/fstab > > Regardless of that though, the resulting rpm packages for > "base-files-regular" > and "base-files-flash" have the original fstab as in "base-files", which is > different to both the fstabs in packages-split mentioned above. > > I'm looking at what might be causing this, but any idea is welcome. > > Thanks, > Diego > > [-- Attachment #2: Type: text/html, Size: 3387 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-03 17:56 ` Oleksandr Poznyak @ 2016-06-06 13:27 ` Diego 2016-06-27 4:11 ` Paul Eggleton 0 siblings, 1 reply; 22+ messages in thread From: Diego @ 2016-06-06 13:27 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, yocto Hi Oleksandr, In data venerdì 3 giugno 2016 20:56:32, Oleksandr Poznyak ha scritto: > I found that that’s an issue with rpm packages. I didn't expect there might > be some issue with rpm. If you really don't care which package management > system to use, switch to deb: > > PACKAGE_CLASSES = "package_deb" > Thanks for looking at the problem, unfortunately migrating away from rpm is not an option for me at the moment. Is there a bug report for this rpm problem? Should I open one? Thanks, Diego ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-06 13:27 ` Diego @ 2016-06-27 4:11 ` Paul Eggleton 2016-07-01 9:18 ` Diego 0 siblings, 1 reply; 22+ messages in thread From: Paul Eggleton @ 2016-06-27 4:11 UTC (permalink / raw) To: Diego; +Cc: yocto On Mon, 06 Jun 2016 15:27:17 Diego wrote: > Hi Oleksandr, > > In data venerdì 3 giugno 2016 20:56:32, Oleksandr Poznyak ha scritto: > > I found that that’s an issue with rpm packages. I didn't expect there > > might > > be some issue with rpm. If you really don't care which package management > > system to use, switch to deb: > > > > PACKAGE_CLASSES = "package_deb" > > Thanks for looking at the problem, unfortunately migrating away from rpm is > not an option for me at the moment. Is there a bug report for this rpm > problem? Should I open one? I'm not aware of one - could you please file a bug? Have you found any further information? Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-27 4:11 ` Paul Eggleton @ 2016-07-01 9:18 ` Diego 0 siblings, 0 replies; 22+ messages in thread From: Diego @ 2016-07-01 9:18 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto In data lunedì 27 giugno 2016 16:11:30, Paul Eggleton ha scritto: > On Mon, 06 Jun 2016 15:27:17 Diego wrote: > > Hi Oleksandr, > > > > In data venerdì 3 giugno 2016 20:56:32, Oleksandr Poznyak ha scritto: > > > I found that that’s an issue with rpm packages. I didn't expect there > > > might > > > be some issue with rpm. If you really don't care which package > > > management > > > system to use, switch to deb: > > > > > > PACKAGE_CLASSES = "package_deb" > > > > Thanks for looking at the problem, unfortunately migrating away from rpm > > is > > not an option for me at the moment. Is there a bug report for this rpm > > problem? Should I open one? > > I'm not aware of one - could you please file a bug? Have you found any > further information? > Hi Paul and all, I've created one here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9863 Don't know if bug is categorized correctly, but at least it is a starting point. Thanks, Diego ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-01 18:57 ` Oleksandr Poznyak 2016-06-03 13:52 ` Diego @ 2016-06-06 20:55 ` Edward Wingate 2016-06-06 21:10 ` Oleksandr Poznyak 1 sibling, 1 reply; 22+ messages in thread From: Edward Wingate @ 2016-06-06 20:55 UTC (permalink / raw) To: Oleksandr Poznyak, Paul Eggleton, yocto, Diego On Wed, Jun 1, 2016 at 7:15 PM, Diego <diego.ml@zoho.com> wrote: > > Hi Oleksandr, > > your approach is really interesting, but I'm unsure how to proceed with > step 2) of your list. > > I've added the following in the bbappend: > > python do_package_prepend() { > d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular ${PN}-fstab-flash") > } > > which creates the two additional packages, but then I'm confused on how to > manage the two 'variant' fstab files. The FILES variable doesn't support > "source -> destination", so how do I manage the fact that two different > files need to go to the same destination path? > > An easier option would be to remove fstab in the base-files_%s.bbappend, > and create 2 different .bb recipes for the 2 fstab files. I hope you don't mind if I tag onto this thread, but I have a similar question. I've been modifying inittab with a sysvinit-inittab_2.88dsf.bbappend file that contains simply this: do_install_append() { echo "scra:2345:respawn:/opt/script1.sh" >> ${D}${sysconfdir}/inittab echo "scrb:2345:respawn:/opt/script2.sh" >> ${D}${sysconfdir}/inittab } Now, I want to do this if a different image is being created: do_install_append() { echo "scra:2345:respawn:/opt/script3.sh" >> ${D}${sysconfdir}/inittab echo "scrb:2345:respawn:/opt/script4.sh" >> ${D}${sysconfdir}/inittab } Can I duplicate and rename the bbappend file to have a different bbappend execute based on the image being created? Or perhaps duplicate the do_install_append() function in the same file and rename the functions to something like do_install_append_[something with image name]()? Or alternatively, can I set something in the image bb files that I can then use in the sysvinit-inittab_2.88dsf.bbappend to determine which to do? Thanks for your help. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-06 20:55 ` Edward Wingate @ 2016-06-06 21:10 ` Oleksandr Poznyak 2016-06-06 22:06 ` Edward Wingate 2016-06-07 10:20 ` Paul Eggleton 0 siblings, 2 replies; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-06 21:10 UTC (permalink / raw) To: Edward Wingate; +Cc: Paul Eggleton, Diego, yocto [-- Attachment #1: Type: text/plain, Size: 2442 bytes --] Hi, Unfortunately You can't have two *.bbappend files per one package (recipe). You can create two new recipes where You'll install what You need and plus add sysvinit-inittab to DEPENDS variable in those recipes. This will help to retain the order of packages installation. Original sysvinit -> your sysvinit. In this situation You will have several recipes. Thanks, Oleksandr Poznyak! On Mon, Jun 6, 2016 at 11:55 PM, Edward Wingate <edwingate8@gmail.com> wrote: > On Wed, Jun 1, 2016 at 7:15 PM, Diego <diego.ml@zoho.com> wrote: > > > > Hi Oleksandr, > > > > your approach is really interesting, but I'm unsure how to proceed with > > step 2) of your list. > > > > I've added the following in the bbappend: > > > > python do_package_prepend() { > > d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular > ${PN}-fstab-flash") > > } > > > > which creates the two additional packages, but then I'm confused on how > to > > manage the two 'variant' fstab files. The FILES variable doesn't support > > "source -> destination", so how do I manage the fact that two different > > files need to go to the same destination path? > > > > An easier option would be to remove fstab in the base-files_%s.bbappend, > > and create 2 different .bb recipes for the 2 fstab files. > > I hope you don't mind if I tag onto this thread, but I have a similar > question. > > I've been modifying inittab with a sysvinit-inittab_2.88dsf.bbappend > file that contains simply this: > > do_install_append() { > echo "scra:2345:respawn:/opt/script1.sh" >> ${D}${sysconfdir}/inittab > echo "scrb:2345:respawn:/opt/script2.sh" >> ${D}${sysconfdir}/inittab > } > > Now, I want to do this if a different image is being created: > > do_install_append() { > echo "scra:2345:respawn:/opt/script3.sh" >> ${D}${sysconfdir}/inittab > echo "scrb:2345:respawn:/opt/script4.sh" >> ${D}${sysconfdir}/inittab > } > > Can I duplicate and rename the bbappend file to have a different > bbappend execute based on the image being created? Or perhaps > duplicate the do_install_append() function in the same file and rename > the functions to something like do_install_append_[something with > image name]()? > > Or alternatively, can I set something in the image bb files that I can > then use in the sysvinit-inittab_2.88dsf.bbappend to determine which > to do? > > Thanks for your help. > [-- Attachment #2: Type: text/html, Size: 3216 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-06 21:10 ` Oleksandr Poznyak @ 2016-06-06 22:06 ` Edward Wingate 2016-06-06 23:52 ` Edward Wingate 2016-06-07 10:20 ` Paul Eggleton 1 sibling, 1 reply; 22+ messages in thread From: Edward Wingate @ 2016-06-06 22:06 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, Diego, yocto On Mon, Jun 6, 2016 at 2:10 PM, Oleksandr Poznyak <oleksandr.poznyak@gmail.com> wrote: > Hi, > Unfortunately You can't have two *.bbappend files per one package (recipe). > > You can create two new recipes where You'll install what You need and plus > add sysvinit-inittab to DEPENDS variable in those recipes. This will help to > retain the order of packages installation. Original sysvinit -> your > sysvinit. > > In this situation You will have several recipes. I create two new recipes: image1-inittab.bb and image2-inittab.bb The are identical except for their do_install_append() function: [image1-inittab.bb] LICENSE = "BSD" LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412" SRC_URI = "file://LICENSE" S = "${WORKDIR}" DEPENDS += " sysvinit-inittab" do_install_append() { echo "scra:2345:respawn:/opt/script1.sh" >> ${D}${sysconfdir}/inittab echo "scrb:2345:respawn:/opt/script2.sh" >> ${D}${sysconfdir}/inittab } [image2-inittab.bb] LICENSE = "BSD" LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412" SRC_URI = "file://LICENSE" S = "${WORKDIR}" DEPENDS += " sysvinit-inittab" do_install_append() { echo "scra:2345:respawn:/opt/script3.sh" >> ${D}${sysconfdir}/inittab echo "scrb:2345:respawn:/opt/script4.sh" >> ${D}${sysconfdir}/inittab } Is this the gist of what needs to be done? I get this error when creating either image: | DEBUG: Executing shell function do_install | /mnt/drive3/yocto/jethro/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/image1-inittab/1.0-r0/temp/run.do_install.23229: 108: /mnt/drive3/yocto/jethro/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/image1-inittab/1.0-r0/temp/run.do_install.23229: cannot create /mnt/drive3/yocto/jethro/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/image1-inittab/1.0-r0/image/etc/inittab: Directory nonexistent | WARNING: exit code 2 from a shell command. It seems I cannot just append to inittab using the echo statements because /etc/inittab is not part of this recipe. Must I duplicate inittab first in my imageX-inittab.bb recipes? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-06 22:06 ` Edward Wingate @ 2016-06-06 23:52 ` Edward Wingate 0 siblings, 0 replies; 22+ messages in thread From: Edward Wingate @ 2016-06-06 23:52 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, Diego, yocto On Mon, Jun 6, 2016 at 3:06 PM, Edward Wingate <edwingate8@gmail.com> wrote: > It seems I cannot just append to inittab using the echo statements > because /etc/inittab is not part of this recipe. Must I duplicate > inittab first in my imageX-inittab.bb recipes? I modified the recipes to include their own copy of inittab: LICENSE = "BSD" LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412" SRC_URI = "file://LICENSE file://inittab-imageX" S = "${WORKDIR}" DEPENDS += " sysvinit-inittab" FILES_${PN} = "/etc/inittab" do_install () { install -d ${D}${sysconfdir} install -m 0644 -D ${S}/inittab-imageX ${D}${sysconfdir}/inittab } Everything builds successfully, but the inittab in the final image is neither image1-inittab's nor image2-inittab's. It is still using sysvinit-inittab's version of inittab. What else do I need to do so it will use my imageX-inittab.bb recipe's version? Thanks for your help! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-06 21:10 ` Oleksandr Poznyak 2016-06-06 22:06 ` Edward Wingate @ 2016-06-07 10:20 ` Paul Eggleton 2016-06-07 10:51 ` Oleksandr Poznyak 2016-06-07 15:57 ` Edward Wingate 1 sibling, 2 replies; 22+ messages in thread From: Paul Eggleton @ 2016-06-07 10:20 UTC (permalink / raw) To: yocto; +Cc: Diego On Tue, 07 Jun 2016 00:10:58 Oleksandr Poznyak wrote: > Unfortunately You can't have two *.bbappend files per one package (recipe). Let's clarify that for the benefit of others reading along - you absolutely *can* have multiple bbappends per recipe. To answer the original question though, no you cannot have bbappends conditionally applied based on what image is being built - you cannot have other recipes built differently based on the image being built *period*. Other than what gets shared via the sysroot, recipes are largely independent of eachother, and that's by design. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 10:20 ` Paul Eggleton @ 2016-06-07 10:51 ` Oleksandr Poznyak 2016-06-07 15:57 ` Edward Wingate 1 sibling, 0 replies; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-07 10:51 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto, Diego [-- Attachment #1: Type: text/plain, Size: 844 bytes --] Thanks, Paul. You are absolutely correct. On Tue, Jun 7, 2016 at 1:20 PM, Paul Eggleton <paul.eggleton@linux.intel.com > wrote: > On Tue, 07 Jun 2016 00:10:58 Oleksandr Poznyak wrote: > > Unfortunately You can't have two *.bbappend files per one package > (recipe). > > Let's clarify that for the benefit of others reading along - you absolutely > *can* have multiple bbappends per recipe. To answer the original question > though, no you cannot have bbappends conditionally applied based on what > image > is being built - you cannot have other recipes built differently based on > the > image being built *period*. Other than what gets shared via the sysroot, > recipes are largely independent of eachother, and that's by design. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > [-- Attachment #2: Type: text/html, Size: 1257 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 10:20 ` Paul Eggleton 2016-06-07 10:51 ` Oleksandr Poznyak @ 2016-06-07 15:57 ` Edward Wingate 2016-06-07 20:47 ` Paul Eggleton 1 sibling, 1 reply; 22+ messages in thread From: Edward Wingate @ 2016-06-07 15:57 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto, Diego On Tue, Jun 7, 2016 at 3:20 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > Let's clarify that for the benefit of others reading along - you absolutely > *can* have multiple bbappends per recipe. To answer the original question > though, no you cannot have bbappends conditionally applied based on what image > is being built - you cannot have other recipes built differently based on the > image being built *period*. Other than what gets shared via the sysroot, > recipes are largely independent of eachother, and that's by design. Thank you, I will abandon that line of inquiry. So I now have recipes that attempt to overwrite inittab with their own custom version. These individual recipes are included in different images and have DEPENDS += " sysvinit-inittab" in them. However, the resulting image still has the original inittab from sysvinit-inittab recipe, not the custom inittab in my new recipes. My recipes look like this now: LICENSE = "BSD" LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412" SRC_URI = "file://LICENSE file://inittab-imageX" S = "${WORKDIR}" DEPENDS += " sysvinit-inittab" FILES_${PN} = "/etc/inittab" do_install () { install -d ${D}${sysconfdir} install -m 0644 -D ${S}/inittab-imageX ${D}${sysconfdir}/inittab } Is there something more I'm missing? Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 15:57 ` Edward Wingate @ 2016-06-07 20:47 ` Paul Eggleton 2016-06-07 23:07 ` Edward Wingate 0 siblings, 1 reply; 22+ messages in thread From: Paul Eggleton @ 2016-06-07 20:47 UTC (permalink / raw) To: Edward Wingate; +Cc: yocto, Diego On Tue, 07 Jun 2016 08:57:24 Edward Wingate wrote: > On Tue, Jun 7, 2016 at 3:20 AM, Paul Eggleton > > <paul.eggleton@linux.intel.com> wrote: > > Let's clarify that for the benefit of others reading along - you > > absolutely > > *can* have multiple bbappends per recipe. To answer the original question > > though, no you cannot have bbappends conditionally applied based on what > > image is being built - you cannot have other recipes built differently > > based on the image being built *period*. Other than what gets shared via > > the sysroot, recipes are largely independent of eachother, and that's by > > design. > > Thank you, I will abandon that line of inquiry. > > So I now have recipes that attempt to overwrite inittab with their own > custom version. These individual recipes are included in different > images and have DEPENDS += " sysvinit-inittab" in them. However, the > resulting image still has the original inittab from sysvinit-inittab > recipe, not the custom inittab in my new recipes. > > My recipes look like this now: > > LICENSE = "BSD" > LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412" > SRC_URI = "file://LICENSE file://inittab-imageX" > S = "${WORKDIR}" > DEPENDS += " sysvinit-inittab" > > FILES_${PN} = "/etc/inittab" > > do_install () { > install -d ${D}${sysconfdir} > install -m 0644 -D ${S}/inittab-imageX ${D}${sysconfdir}/inittab > } > > Is there something more I'm missing? Thanks. So what this will give you is alternative packages to be installed instead of sysvinit-inittab in your image. Have you verified (by way of the image manifest written next to the image file) that this package is actually being installed? What steps have you taken to ensure that it does get installed in preference to sysvinit-inittab? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 20:47 ` Paul Eggleton @ 2016-06-07 23:07 ` Edward Wingate 2016-06-07 23:23 ` Paul Eggleton 0 siblings, 1 reply; 22+ messages in thread From: Edward Wingate @ 2016-06-07 23:07 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto, Diego On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > > So what this will give you is alternative packages to be installed instead of > sysvinit-inittab in your image. I was under the (mistaken) impression that my recipe will run in addition to, not instead of, sysvinit-inittab (occurring after it and overwriting its inittab with my custom version). > Have you verified (by way of the image manifest written next to the image file) that this package > is actually being installed? The manifest shows both sysvinit-inittab and my package being installed in the image, but sysvinit-inittab's inittab apparently takes precedence over mine. > What steps have you taken to ensure that it does get installed in preference to sysvinit-inittab? None, due to my mistaken impression. After investigating your kind inference with help of Yocto manual, I replaced in my recipe: DEPENDS += " sysvinit-inittab" with: RREPLACES_${PN} = "sysvinit-inittab" and it appears to be working now. I've been using Yocto for a year now, but still feel like I'm barely scratching the surface of it. I tend to get things to work by floundering about, so even though it does works, I would appreciate knowing if this was the most proper course of action. Thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 23:07 ` Edward Wingate @ 2016-06-07 23:23 ` Paul Eggleton 2016-06-08 8:58 ` Oleksandr Poznyak 0 siblings, 1 reply; 22+ messages in thread From: Paul Eggleton @ 2016-06-07 23:23 UTC (permalink / raw) To: Edward Wingate; +Cc: yocto, Diego On Tue, 07 Jun 2016 16:07:26 Edward Wingate wrote: > On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton > <paul.eggleton@linux.intel.com> wrote: > > So what this will give you is alternative packages to be installed instead > > of sysvinit-inittab in your image. > > I was under the (mistaken) impression that my recipe will run in > addition to, not instead of, sysvinit-inittab (occurring after it and > overwriting its inittab with my custom version). The recipe will build in addition to sysvinit-inittab yes, but do_install for that recipe is just assembling the files ready for packaging - it doesn't directly install files into the image. When it comes time to assemble the image, all that is being done when you distil it down is that we install a bunch of packages. > > Have you verified (by way of the image manifest written next to the image > > file) that this package is actually being installed? > > The manifest shows both sysvinit-inittab and my package being > installed in the image, but sysvinit-inittab's inittab apparently > takes precedence over mine. Hmm, that is strange, because as they install the same file they ought to conflict. Perhaps as suggested elsewhere in this thread this is a bug (or at least undesirable behaviour) in rpm. > > What steps have you taken to ensure that it does get installed in > > preference to sysvinit-inittab? > > None, due to my mistaken impression. After investigating your kind > inference with help of Yocto manual, I replaced in my recipe: > DEPENDS += " sysvinit-inittab" > with: > RREPLACES_${PN} = "sysvinit-inittab" > > and it appears to be working now. I've been using Yocto for a year > now, but still feel like I'm barely scratching the surface of it. I > tend to get things to work by floundering about, so even though it > does works, I would appreciate knowing if this was the most proper > course of action. Thanks! I guess here you are getting into functionality that is not very well-defined, and you're also dealing with behaviour of the package manager rather than the build system itself (though I appreciate the lines are blurred from usage perspective). I guess it would help though if we would document a working procedure to do this kind of thing as it does come up from time to time. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-07 23:23 ` Paul Eggleton @ 2016-06-08 8:58 ` Oleksandr Poznyak 2016-06-08 18:01 ` Edward Wingate 0 siblings, 1 reply; 22+ messages in thread From: Oleksandr Poznyak @ 2016-06-08 8:58 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto, Diego [-- Attachment #1: Type: text/plain, Size: 2990 bytes --] Hi, Edward. Your approach is valid. But RREPLACES is not enough. You should define that your package and original ones are conflicting and that it provides the same as original one for other packages. So in your recipe: RPROVIDES_${PN} = "sysvinit-inittab" RREPLACES_${PN} = "sysvinit-inittab" RCONFLICTS_${PN} = "sysvinit-inittab" Thanks, Oleksandr Poznyak! On Wed, Jun 8, 2016 at 2:23 AM, Paul Eggleton <paul.eggleton@linux.intel.com > wrote: > On Tue, 07 Jun 2016 16:07:26 Edward Wingate wrote: > > On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton > > <paul.eggleton@linux.intel.com> wrote: > > > So what this will give you is alternative packages to be installed > instead > > > of sysvinit-inittab in your image. > > > > I was under the (mistaken) impression that my recipe will run in > > addition to, not instead of, sysvinit-inittab (occurring after it and > > overwriting its inittab with my custom version). > > The recipe will build in addition to sysvinit-inittab yes, but do_install > for > that recipe is just assembling the files ready for packaging - it doesn't > directly install files into the image. When it comes time to assemble the > image, all that is being done when you distil it down is that we install a > bunch of packages. > > > > Have you verified (by way of the image manifest written next to the > image > > > file) that this package is actually being installed? > > > > The manifest shows both sysvinit-inittab and my package being > > installed in the image, but sysvinit-inittab's inittab apparently > > takes precedence over mine. > > Hmm, that is strange, because as they install the same file they ought to > conflict. Perhaps as suggested elsewhere in this thread this is a bug (or > at > least undesirable behaviour) in rpm. > > > > What steps have you taken to ensure that it does get installed in > > > preference to sysvinit-inittab? > > > > None, due to my mistaken impression. After investigating your kind > > inference with help of Yocto manual, I replaced in my recipe: > > DEPENDS += " sysvinit-inittab" > > with: > > RREPLACES_${PN} = "sysvinit-inittab" > > > > and it appears to be working now. I've been using Yocto for a year > > now, but still feel like I'm barely scratching the surface of it. I > > tend to get things to work by floundering about, so even though it > > does works, I would appreciate knowing if this was the most proper > > course of action. Thanks! > > I guess here you are getting into functionality that is not very > well-defined, > and you're also dealing with behaviour of the package manager rather than > the > build system itself (though I appreciate the lines are blurred from usage > perspective). I guess it would help though if we would document a working > procedure to do this kind of thing as it does come up from time to time. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > [-- Attachment #2: Type: text/html, Size: 3768 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Per image customizations 2016-06-08 8:58 ` Oleksandr Poznyak @ 2016-06-08 18:01 ` Edward Wingate 0 siblings, 0 replies; 22+ messages in thread From: Edward Wingate @ 2016-06-08 18:01 UTC (permalink / raw) To: Oleksandr Poznyak; +Cc: Paul Eggleton, Diego, yocto On Wed, Jun 8, 2016 at 1:58 AM, Oleksandr Poznyak <oleksandr.poznyak@gmail.com> wrote: > Hi, Edward. > Your approach is valid. But RREPLACES is not enough. > > You should define that your package and original ones are conflicting and > that it provides the same as original one for other packages. > > So in your recipe: > > RPROVIDES_${PN} = "sysvinit-inittab" > RREPLACES_${PN} = "sysvinit-inittab" > RCONFLICTS_${PN} = "sysvinit-inittab" Thank you, Oleksandr and Paul, for your help and clarification. And in case my hijacking of this thread caused OP's last question to be ignored, I apologize and wish to put the thread back on track for him: On Mon, Jun 6, 2016 at 6:27 AM, Diego <diego.ml@zoho.com> wrote: > Hi Oleksandr, > > In data venerdì 3 giugno 2016 20:56:32, Oleksandr Poznyak ha scritto: >> I found that that’s an issue with rpm packages. I didn't expect there might >> be some issue with rpm. If you really don't care which package management >> system to use, switch to deb: >> >> PACKAGE_CLASSES = "package_deb" >> > > Thanks for looking at the problem, unfortunately migrating away from rpm is > not an option for me at the moment. Is there a bug report for this rpm > problem? Should I open one? ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-07-01 9:19 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-31 16:05 Per image customizations Diego 2016-05-31 23:57 ` Paul Eggleton 2016-06-01 12:25 ` Oleksandr Poznyak 2016-06-01 16:15 ` Diego 2016-06-01 18:57 ` Oleksandr Poznyak 2016-06-03 13:52 ` Diego 2016-06-03 17:56 ` Oleksandr Poznyak 2016-06-06 13:27 ` Diego 2016-06-27 4:11 ` Paul Eggleton 2016-07-01 9:18 ` Diego 2016-06-06 20:55 ` Edward Wingate 2016-06-06 21:10 ` Oleksandr Poznyak 2016-06-06 22:06 ` Edward Wingate 2016-06-06 23:52 ` Edward Wingate 2016-06-07 10:20 ` Paul Eggleton 2016-06-07 10:51 ` Oleksandr Poznyak 2016-06-07 15:57 ` Edward Wingate 2016-06-07 20:47 ` Paul Eggleton 2016-06-07 23:07 ` Edward Wingate 2016-06-07 23:23 ` Paul Eggleton 2016-06-08 8:58 ` Oleksandr Poznyak 2016-06-08 18:01 ` Edward Wingate
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.