Talk:Auto-Update Patch Technology

Here we can discuss the future of AUPT and where we should go from here. Here are some ideas I've been thinking about for the next generation of AUPT as a C service using AUFS overlay.

Directory Structure

/media/internal/.patches

• patch.db - patch state database file (doesn't -have- to be database?)
• webos-$version/ - version specific overlay
• webos-$version/<package>/ - palm package
• webos-$version/<package>/path/to/files - patched files
• stock/path/to/files - Stock backup files
• work-area/path/to/files - A place to do the actual patching/testing, before copying files to in-use overlay. This will make sure there are fewer chances to have partial-patch installations and other odd issues that may arise. (Is this needed or overkill?)

Each <package> would be an aufs branch. Or maybe the C-service/statefile would keep track of the hunk -> file -> package connection. Today I've been pondering using the source code for GNU patch in the C service.

NO overlay branches

These are branches that will need to not be modified by any custom overlay

• /boot
• /dev
• /proc
• /sys
• /usr/lib/ipkg
• /media/internal
• /lib
• /bin
• /sbin
• /mnt

(Should we just use /usr and /etc as allowable patch branches?)

Statefile

A database state file with patch information may be needed. Possible things to store are the following:

• What palm packages and files each patch touches
• What order the patches were applied in. It may have to be on a per file basis.
• rw aupt branches (see directory structure) - cryptk brings up good point to make the aupt branches ro as well
• ro stock branches (see No overlay branches) marking the overlays as 'dirty' and re-starting the service may be needed for updates to patching service. Possibly provide a way for faulty patches preventing Luna from starting to be detected.
• current webos version

Upstart

Upon booting, the upstart service needs to be started as early as possible to get the aufs overlay over before things like Luna start reading files. The starting of the patch service should do at a bare minimum some sanity checks before mounting the overlay. Some sort of flag for not booting cleanly the last time should be detected if possible.

OTA

Using "stop on started start_update" we can rip out the overlay during a Palm OTA update. On the next boot the webos version will be different and the patch service -could- attempt to re-patch as many 'patches' as possible. Since all the patch packages will change to new feed and require update all via preware anyway, we can just leave this to the user to hit update all instead (as it is now), and then all the patches will be installed to the new webos-version overlay.

Other random things to think about

• what to do with files that are written outside of aupt that will appear in aufs branches?
• Possibly track the version of the palm package that a patch is applied to, rather than assuming webos version means correct package version. Would also allow forward compatibility if Palm ever started allowing package updates without webos version changes.
• Would it be useful to use combinediff on a pacakge (or file) basis?

Continued discussion

• cryptk: "there could be a file that stores the currently selected patch profile, that way the correct aufs overlay is used, after aufs is loaded that file is cleared to be re-written when the upstart service is closed cleanly. then it would double as our bad boot flag"
• multiple webos-version patches in single ipk vs. multiple webos-version feeds