Per image customizations

Per image customizations

[Diego]

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

Re: Per image customizations

[Paul Eggleton]

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

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Diego]

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

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Diego]

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

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Diego]

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

Re: Per image customizations

[Edward Wingate]

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.

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Edward Wingate]

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?

Re: Per image customizations

[Edward Wingate]

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!

Re: Per image customizations

[Paul Eggleton]

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

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Edward Wingate]

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.

Re: Per image customizations

[Paul Eggleton]

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

Re: Per image customizations

[Edward Wingate]

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!

Re: Per image customizations

[Paul Eggleton]

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

Re: Per image customizations

[Oleksandr Poznyak]

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

Re: Per image customizations

[Edward Wingate]

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?

Re: Per image customizations

[Paul Eggleton]

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

Re: Per image customizations

[Diego]

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