ImageBuilder and Custom IPKs vs PACKAGES on command line

For Developers
1

I am having some weird issues with Image Builder and trying to get it to install specific IPKs which I have put in the packages/ folder.

First, it's not clear from the Wiki whether after putting the IPK in the packages folder you also need to specify that same package in the PACKAGES= command line option? It seemed to work both ways in the past but today I needed to build an image from SNAPSHOT and I seemed to get a different version of the package than what was in the IPK if I also put that package in the PACKAGES command line option.

Can someone clear up what is happening here and how it is supposed to work?

My hunch is that if you specify the package on the command line it will try to install it from upstream repository, which would then result in a version standoff, if the upstream package is newer than the IPK it will get installed, if it's older than the IPK the IPK will take precedence. Is that about right? So if you want the specific IPK installed, you need to drop it in the packages/ folder and NOT put it in the command line?

2

If it's a snapshots image builder, you may need to recompile the IPK as APK for it to work as of a few days ago. Also, if the APK is not properly signed, not sure if the APK-aware IB will pick up said package. Finally, the make process for snapshots prepends the r to the PKG_RELEASE number of the package, so any package built without that r in the PKG_RELEASE is considered older than the one with r if the PKG_VERSION is the same.

For 23.05 and earlier image builders you need to both put the IPK into packages/ and add the package name to the PACKAGES variable. If adding multiple packages to the variable, don't forget to use quotes or double-quotes.

3

Thanks this is useful. I'm using a pre-APK snapshot. Is there still the version condition applied then? If the packages feed version is higher than the local version (because of the 'r') then the feed take priority?

This is what I'm seeing, my IPK is version 1.1.0-1 but the version that ends up in the image is 1.1.0-r1

4

AFAIK, 1.1.0-rX is considered a newer/higher version than 1.1.0-Y, whatever values of X and Y are. You may want to bump a PKG_VERSION, not PKG_RELEASE when compiling package to get the IB to pick up the package without the r prefix.

5

I am using IB with custom-built packages. Previouly, custom-built IPKs were picked up by IB without issue. The customed IPKs in packages folder always had higher priority to be picked up than the ones with the same name from official repo.

Now with APK-aware IB, customed APKs seem to be ignored and IB terminated with "unable to select packages" error.

Hopefully, the switch to APK will settle down soon, and docs are updated with new guidance.

6

This was most certainly not my experience and for me the IB would pick the IPK with the higher version number, whatever the source of them was.

Are the custom APKs signed, with the public key from signing available for the IB?

7

Hi. I mainly use IB with BUILD-PATENTED enabled ffmpeg packages and other self-made ones, I am quite certain when customed IPK versions are equal with official repo, customed ones would be picked.

Not sure about lower version pioriority, as I tend to keep my customed packages synced with official repo. But there're times I lagged some days behind and my workflow requiring PATENTED didn't break.

The APKs I want to inject are self-built from buildroot, with BUILD-PATENTED enabled. They may be signed with local-generated keys. IB with opkg just happily accepted them.

But now it's not the case with APK, I am trying to dig into source code to see what happen.

My impressions are APK are stricker with dependency contrains, which does not permit some removal of package commandline options to IB, and IB with APK is slow and can easily hanged with kmod installing.

I think I have to understand IB and APK better to tell it's a bug or feature.