Bug 1893

(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.