On Mar 02, 2014, at 06:50 PM, Зонов Роман wrote:

>"The default update mechanism is therefore image based. We build new images
>on our build infrastructure, generate diffs between images and publish the
>result on the public server." - part of Stéphane Graber's post. Fox example,
>I have...1036 build of UT. Current version is 2056. As far as I understand,
>system-upgrader downloads 2056 build with ONLY difference between 2056 and
>2055 build, isn't it? If it is, it is critical bug.

Dimitri explained the situation well.  I'll add that system-image starts
by calculating *all* available upgrade paths, from where you are to the
highest available image number.  Then it scores the paths, taking into account
various criteria such as totally number of reboots necessary and total
download size.  Eventually, one candidate path will have the winning score and
it will be chosen as your device's upgrade path.

Current scoring goes like this:

    """Use the following inputs and weights. Lowest score wins.

    reboots - Look at the entire path and add 100 for every extra reboot
        required.  The implicit end-of-update reboot is not counted.

    total download size - add 1 for every 1MiB over the smallest image.

    destination build number - absolute value of the total distance from the
        highest version number + 9000.

    ...
    """

The gory details: http://tinyurl.com/m9a9oa8

If you turn on debug logging, the log file will contain all candidate upgrade
paths and their scores.  `system-image-cli --dry-run` shows you the winning
path.  Theoretically, you could design your own scoring algorithm and plug it
into system-image by setting the appropriate value in the client.ini
configuration file.

Cheers,
-Barry

-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to     : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Reply via email to