Makefile: run 'bitbake package-index' after bitbake command building packages #3

Merged
pespin merged 1 commits from pespin/201705 into 201705 2023-06-23 08:36:47 +00:00
Member

It was recently spotted that during a build of 201705-testing where
sysmocom-openvpn-config was being rebuilt, the Packages(.gz) files
(opkg package indexes) were rebuilt before the new .ipk files for
sysmocom-openvpn-config were written to disk. Also then the Packages
file didn't contain a reference to the new sysmocom-openvpn-config
package version. So, it seems there was a race condition where the
package index was built too early.

Yocto documentation provides some hints:
https://docs.yoctoproject.org/dev-manual/packages.html?highlight=bitbake+package+index#build-considerations
"""
Whenever you perform any sort of build step that can potentially generate
a package or modify existing package, it is always a good idea to
re-generate the package index after the build by using the following
command: bitbake package-index
Do not do "$ bitbake some-package package-index" as BitBake does not schedule
the package index for after the completion of the package you are building.
Consequently, you cannot be sure of the package index including
information for the package you just built. Thus, be sure to run the
package update step separately after building any packages.
"""

So far it seems we were relying on the "create filesystem" task
triggered for image creation which would also trigger the package index
recreation, according to
https://yocto.yoctoproject.narkive.com/rjvLrVpW/question-about-rebuilding-rpm-package-index-for-updated-rpms-when-bitbake-completes
"""
The feed is normally indexed (createrepo) either when you manually run the
package-index operation, or when you construct a filesystem. Until you do that,
the feed directories are transient.
"""

Related: SYS#6023

It was recently spotted that during a build of 201705-testing where sysmocom-openvpn-config was being rebuilt, the Packages(.gz) files (opkg package indexes) were rebuilt before the new .ipk files for sysmocom-openvpn-config were written to disk. Also then the Packages file didn't contain a reference to the new sysmocom-openvpn-config package version. So, it seems there was a race condition where the package index was built too early. Yocto documentation provides some hints: https://docs.yoctoproject.org/dev-manual/packages.html?highlight=bitbake+package+index#build-considerations """ Whenever you perform any sort of build step that can potentially generate a package or modify existing package, it is always a good idea to re-generate the package index after the build by using the following command: bitbake package-index Do not do "$ bitbake some-package package-index" as BitBake does not schedule the package index for after the completion of the package you are building. Consequently, you cannot be sure of the package index including information for the package you just built. Thus, be sure to run the package update step separately after building any packages. """ So far it seems we were relying on the "create filesystem" task triggered for image creation which would also trigger the package index recreation, according to https://yocto.yoctoproject.narkive.com/rjvLrVpW/question-about-rebuilding-rpm-package-index-for-updated-rpms-when-bitbake-completes """ The feed is normally indexed (createrepo) either when you manually run the package-index operation, or when you construct a filesystem. Until you do that, the feed directories are transient. """ Related: SYS#6023
pespin added 1 commit 2023-06-22 14:30:37 +00:00
819c17e138 Makefile: run 'bitbake package-index' after bitbake command building packages
It was recently spotted that during a build of 201705-testing where
sysmocom-openvpn-config was being rebuilt, the Packages(.gz) files
(opkg package indexes) were rebuilt before the new .ipk files for
sysmocom-openvpn-config were written to disk. Also then the Packages
file didn't contain a reference to the new sysmocom-openvpn-config
package version. So, it seems there was a race condition where the
package index was built too early.

Yocto documentation provides some hints:
https://docs.yoctoproject.org/dev-manual/packages.html?highlight=bitbake+package+index#build-considerations
"""
Whenever you perform any sort of build step that can potentially generate
a package or modify existing package, it is always a good idea to
re-generate the package index after the build by using the following
command: bitbake package-index
Do not do "$ bitbake some-package package-index" as BitBake does not schedule
the package index for after the completion of the package you are building.
Consequently, you cannot be sure of the package index including
information for the package you just built. Thus, be sure to run the
package update step separately after building any packages.
"""

So far it seems we were relying on the "create filesystem" task
triggered for image creation which would also trigger the package index
recreation, according to
https://yocto.yoctoproject.narkive.com/rjvLrVpW/question-about-rebuilding-rpm-package-index-for-updated-rpms-when-bitbake-completes
"""
The feed is normally indexed (createrepo) either when you manually run the
package-index operation, or when you construct a filesystem. Until you do that,
the feed directories are transient.
"""

Related: SYS#6023
osmith approved these changes 2023-06-23 08:35:10 +00:00
pespin merged commit 819c17e138 into 201705 2023-06-23 08:36:47 +00:00
pespin deleted branch pespin/201705 2023-06-23 08:36:47 +00:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sysmo-bts/system-images#3
No description provided.