[pacman-dev] delta support in libalpm

[Aaron Griffin]

On Fri, Feb 27, 2009 at 10:14 AM, Xavier <shiningxc at gmail.com> wrote:
> On Fri, Feb 27, 2009 at 4:55 PM, Aaron Griffin <aaronmgriffin at 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.