I noticed that the OE build process is leaving files at /var/lib/opkg/lists (~1.5 MB on my system), which I believe are the feed content used to build the image. The target opkg.conf file configure lists_dir to be at /var/lib/opkg (instead of the default /var/lib/opkg/lists), so the feed content under /var/lib/opkg/lists is not used at all. Commit d950ef40a3eae4b54cc62828e66d84a62d78c447 removed: rm -f ${IMAGE_ROOTFS}${OPKGLIBDIR}/opkg/lists/* step which was not implemented on rootfs.py.
I am not able to reproduce this, /var/lib/opkg/lists does in fact exist, but it seems to be empty in my builds, is there anything else on your configuration that might be affecting this?
You are right, the folder is incorrectly left-over, but it is empty (I must have been running another test, which filled it). From what I can tell, opkg default lists_dir folder is /var/lib/opkg/lists, which is created during opkg update if it doesn't exists. If the conf file /etc/opkg/opkg.conf doesn't have a lists_dir entry, then it goes with the default. I think that's what happens during the offline root image creation. The inconsistency comes from the fact that the opkg-collateral recipes defaults lists_dir to /var/lib/opkg: echo "lists_dir ext ${OPKGLIBDIR}/opkg" >>${WORKDIR}/opkg.conf
It appears the NEEDINFO has been completed. Please put this back in NEEDINFO if there are still questions.
(In reply to comment #2) > You are right, the folder is incorrectly left-over, but it is empty (I must > have been running another test, which filled it). > > From what I can tell, opkg default lists_dir folder is /var/lib/opkg/lists, > which is created during opkg update if it doesn't exists. If the conf file > /etc/opkg/opkg.conf doesn't have a lists_dir entry, then it goes with the > default. I think that's what happens during the offline root image creation. > > The inconsistency comes from the fact that the opkg-collateral recipes > defaults lists_dir to /var/lib/opkg: > > echo "lists_dir ext ${OPKGLIBDIR}/opkg" >>${WORKDIR}/opkg.conf Ok, we should probably solve inconsistencies by using /var/lib/opkg/lists, but I still need to check, because this "default" behavior might be caused by the line EXTRA_OE_CONF = "--with-opkglibdir=${OPKGLIBDIR}" in our recipe, which according to opkg's git repository, that option was replaced since opkg v0.3.0
Well... for starters were barely on opkg v0.2.4, secondly about some of the comments before, depending on how we're adding package management to the image we get two different behaviors, if we do it via an IMAGE_FEATURE the lists are populated, hence the extra 1.5MB mentioned before, but if we do it via installing the opkg package, then the list aren't populated initially, this is apparently desired behavior so we should leave it to the user to decide which behavior is more accurate for a specific applciation. In any way, inconsistencies should be resolved by using the same lists directory which will end up being "/var/lib/opkg/lists", sending patch to list.
Fixed: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e87b533b2f773ac00bf0acf2ba44c5c98235a383
Verified on master e35c404537db0b46047fcb2ee7d3645e3e0935c5 Directory is updated after: opkg update with correct information. Still the original information is NOT correct: oe, oe-all, oe-i586 and oe-qemux86 are pointing to some directories that were on the system where qemu image was built! root@qemux86:/var/lib/opkg/lists# ls -ila 2338 drwxr-xr-x 2 root root 1024 Oct 20 12:36 . 833 drwxr-xr-x 4 root root 1024 Oct 20 11:29 .. 9442 -rw-r--r-- 1 root root 37868 Oct 20 13:01 all 9446 -rw-r--r-- 1 root root 6032588 Oct 20 13:01 i586 2339 lrwxrwxrwx 1 root root 59 Oct 20 12:16 oe -> /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/Packages 2340 lrwxrwxrwx 1 root root 63 Oct 20 12:16 oe-all -> /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/all/Packages 2341 lrwxrwxrwx 1 root root 64 Oct 20 12:16 oe-i586 -> /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/i586/Packages 2342 lrwxrwxrwx 1 root root 67 Oct 20 12:16 oe-qemux86 -> /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/qemux86/Packages 9444 -rw-r--r-- 1 root root 332247 Oct 20 13:01 qemux86 Observe root@qemux86:/var/lib/opkg/lists# ls oe-i586 ls: oe-i586: No such file or directory
This was REOPENED
(In reply to comment #7) > Verified on master e35c404537db0b46047fcb2ee7d3645e3e0935c5 > Directory is updated after: opkg update with correct information. > > > Still the original information is NOT correct: oe, oe-all, oe-i586 and > oe-qemux86 are pointing to some directories that were on the system where > qemu image was built! > > root@qemux86:/var/lib/opkg/lists# ls -ila > 2338 drwxr-xr-x 2 root root 1024 Oct 20 12:36 . > 833 drwxr-xr-x 4 root root 1024 Oct 20 11:29 .. > 9442 -rw-r--r-- 1 root root 37868 Oct 20 13:01 all > 9446 -rw-r--r-- 1 root root 6032588 Oct 20 13:01 i586 > 2339 lrwxrwxrwx 1 root root 59 Oct 20 12:16 oe -> > /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/Packages > 2340 lrwxrwxrwx 1 root root 63 Oct 20 12:16 oe-all -> > /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/all/Packages > 2341 lrwxrwxrwx 1 root root 64 Oct 20 12:16 oe-i586 -> > /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/i586/Packages > 2342 lrwxrwxrwx 1 root root 67 Oct 20 12:16 oe-qemux86 > -> /home/yocto/yocto/BBB/Bug8048/build/tmp/deploy/ipk/qemux86/Packages > 9444 -rw-r--r-- 1 root root 332247 Oct 20 13:01 qemux86 > > Observe > root@qemux86:/var/lib/opkg/lists# ls oe-i586 > ls: oe-i586: No such file or directory Again, I am not able to reproduce this, I tried both methods (including opkg on the image, and also via IMAGE_FEATURES, to me the "lists" doesn't exist, it is created after running opkg update, but still after it's empty: root@qemux86:/var/lib/opkg# ls root@qemux86:/var/lib/opkg# opkg update root@qemux86:/var/lib/opkg# ls info lists root@qemux86:/var/lib/opkg# cd lists/ root@qemux86:/var/lib/opkg/lists# ls -l total 0 Could this be happening because of another test you are running?
Looks ok now.
Verified on master 8037ba4d86a65ee296cfdcee736dfd614c568818