Please refer to http://bugzilla.pokylinux.org/show_bug.cgi?id=1651 we divide the 1651 into 3 part: the rpm, deb and ipk, the rpm and deb part will be done in M3, this one is for deb.
(In reply to comment #0) > Please refer to http://bugzilla.pokylinux.org/show_bug.cgi?id=1651 > > we divide the 1651 into 3 part: the rpm, deb and ipk, the rpm and deb part Sorry for the typo, it should be: the ipk and deb part will be done in M3, the rpm part has been done. > will be done in M3, this one is for deb.
We may not do it in 1.2, has talked with Song Liu about this
I found that the following two tasks can't be done because of the limitation of opkg-cl and apt-get utilities: 1894 Incremental IPK image generation (Developing) 1893 Incremental DEB image generation (May not do it in 1.2 as talked before) If we want the incremental image generation, we need the following 3 types information: 1) which pkg would be newly installed 2) which pkg would be removed 3) which pkg has been changed since the last generation To get the 3 types of information, we need to know the pkg list that has been installed, and the pkg list that *to be* installed, for the rpm pkg, this is ok, (and the RPM part has been done in M2), but for the ipk or deb, we can't the integrity pkg list that would be installed, the opkg-cl or apt-get would install the pkg according to the "Depends" and "Recommends", also maybe the "Suggests" or "Conflicts" (Priority?), I tried to write a script to figure out the pkg that to be installed, but the result is not what we need: 1) If I just grab the pkg from "Depends" area, then the result would be less than the pkgs that really installed. 2) If I grab the pkg from both the "Depends" and "Recommends" area, then the result(pkg_to_be) would be more than the pkgs that really installed (pkg_installed), and some pkg in pkg_installed is still not in pkg_to_be list Things seems complicated than what I thought before, we may need re-implement the algorithm of opkg-cl and apt-get, but this seems not worth. So I suggested that we don't do it any more.
Here is the Design document:(For the deb based rootfs) * Usage: 1) Add the follow config option to a conf file: INC_DEB_IMAGE_GEN = "1" 2) bitbake core-image-sato modify a package bitbake core-image-sato The rootfs ould not be totally removed and re-created in the second generation, it would be simply updated based on the "package" * Implementation: 1) Invoke "apt-get install pkg-name" to install all pkgs, the newly added pkgs will be installed automaticly. 2) Figure out all pkg names which need *to be* installed currently by invoking "apt-get install -s", and get a currently installed list. To achieve *to be*, we need to backup and clear dpkg database before invoking "apt-get install -s", and recover it after *to be* has been finished. 3) If deb incremental generation is supported: 3.1) Use currently *to be* installed list to compare with the previ- ously installed list to get which of them need to be removed. 3.2) Remove unused pkgs and old version pkgs by invoking "apt-get purge pkg-name" 3.3) Attempt to correct broken dependencies by invoke "apt-get install pkg-name" again. This will install the new version pkgs, so the upgrade is finished. 3.4) Pkg upgrade is finished by step 3.2) and 3.3): remove the old version pkg first and then install the new version. The same like that, pkg downgrade is also supported, that's why we don't choose "apt-get dist-upgrade". 4) Keep the currently *to be* installed list as already installed list for the next time.
The following is the test case about how to test incremental deb image generation: 1, Modify a package 1) Add the follow config option to a conf file: INC_DEB_IMAGE_GEN = "1" PACKAGE_CLASSES = "package_deb" 2) Run `bitbake core-image-sato' and test the image could work correctly. 3) Modify a package, such as busybox_1.20.2.bb. 4) Run `bitbake core-image-sato' 5) vim log.do_rootfs to see if the following log exists: `NOTE: Updating ***' 6) runqemu qemux86 2, Remove a package 1) Add the following line to conf/local.conf: INC_DEB_IMAGE_GEN = "1" PACKAGE_CLASSES = "package_deb" 2) Run "bitbake core-image-sato" to build an image 3) Comment out IMAGE_FEATURES in /meta/recipes-sato/images/core-image-sato.bb 4) Run "bitbake core-image-sato" to build an image 5) vim log.do_rootfs to see if the following log exists: `NOTE: Removing ***' 3, Add a package 1) Add the following line to conf/local.conf: INC_DEB_IMAGE_GEN = "1" PACKAGE_CLASSES = "package_deb" 2) Do the above removing case. 3) Uncomment IMAGE_FEATURES in /meta/recipes-sato/images/core-image-sato.bb 4) Run `bitbake core-image-sato' to build an image 5) runqemu qemux86
Support incremental deb image generation, here is the design: 1) Update packages index file in ${DEPLOY_DIR_DEB}, and figure out newly added packages at current image session comparing with previous image session. 2) Config apt 3) If not support incremental deb image generation 1, Install packages additional for uclibc, normal, attempt only. 2, Dump solution manifest which lists all the *to be installed* packages including 1, and the automatically installed according to the dependencies. 4) else if support incremental deb image generation 1, Collect *to be installed* packages which include additional for uclibc, normal, attempt only and don't include automatically installed by RDEPENDS. 2, Dump solution manifest which lists all the *to be installed* packages including 1, and the automatically installed according to the dependencies. 3, Figure out unused packages, they are in the installed manifest and not in the solution manifest. 4, Remove unused packages. 5, Figure out existed packages, they are in both the solution manifest and the installed manifest. 6, Figure out updated packages, they belong to both the existed packages and newly added packages. 7, Reinstall updated packages. 5) Change solution manifest to installed manifest for next image session. 6) Back up dpkg database for next image session.
Move to 1.6
We no plans to implement this feature for debian packaging.