On Fri, Feb 27, 2009 at 10:14 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Feb 27, 2009 at 4:55 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Hmm, good questions. I was thinking that we would simply run "repo-add --deltas" or something, but it still requires us to figure out the old package file and copy that as well.
That's the main issue here - determining the old/existing package file. I guess it's not TOO hard, the more I think about it. I'll just have to extract the DB and parse through it, unless someone else can figure out a cleaner way to get the filename for an old package from a DB knowing the new package's name (and version and all the other meta info)
To do this in the db-scripts, we need to open the existing DB, find the entry for this pkgname, and get the filename. Does pkgdelta correctly construct deltas in different directories, or do we also need to copy the file next to the new package before running pkgdelta need to be next to each other?
The old package and new package can be anywhere. But the new delta will be put next to the new package. What would be the best output location for the new delta?
That works fine. The way the dbscripts do operations is by: a) locking the existing DB (with a lock file) b) copying the db file to a temp dir c) copying all staging files to that temp dir d) adding everything to the db e) copying the entire temp dir to the existing db location f) unlocking the db
So putting deltas in-place works fine - I was just hoping we wouldn't have to figure out additional files to copy to the temp dir for deltas
So, even if repo-add finds the old filename, which is easy to do, it is not going to know in which directory that old package actually sits. That's a big problem, I started to add delta generation to repo-add but we have a show stopper here.
Here is the code I used to find the old filename : pkgentry=$(find_pkgentry $pkgname) if [ -n "$pkgentry" ]; then oldfilename=$(grep -A1 FILENAME $pkgentry/desc | tail -n1) oldfile="$(dirname $1)/$oldfilename" fi
So here I assumed that the old package file sits in the same directory that the new package file (dirname $1), which is not the case in dbscripts.
find_pkgentry was already defined in repo-add so that was practical to re-use.
find_pkgentry() { local pkgname=$1 local pkgentry for pkgentry in $gstmpdir/$pkgname*; do name=${pkgentry##*/} if [ "${name%-*-*}" = "$pkgname" ]; then echo $pkgentry return 0 fi done return 1 }
Yeah, this stuff probably fits better in the dbscripts, due to this discrepancy. The reason we don't do these operations directly in the DB dir is so that we can fail without too much cleanup, and so we can prevent things from rsyncing when we are in the middle of an update.