[pacman-dev] Move -Sw to front-end

Nagy Gabor ngaba at bibl.u-szeged.hu
Tue Aug 26 10:28:41 EDT 2008


After moving -Sp to front-end I decided to move -Sw as well, thus we
would reach the following goal: alpm_trans_commit represents a _real_
transaction, ie. its successful run will cause a localdb change.

It would make our code much more understandable, for example we could
simply move ldconfig call to trans_commit (this would fix the duplicated
ldconfig run issue on -Su %REPLACES%) and this would be helpful in my
refresh_pkgcache branch etc.

The reason for not providing a patch, I couldn't decide how to make
this "download part" public. (This should be factorised from
sync_commit). I put some ideas/opinions here, some of them may be
conflicting. I appreciate any feedback.

1. Pre-condition: download callback stuffs are attached to handle, not
to trans. Cool, "nice" transaction independent download stuff is
2. First I thought something like this:
alpm_download_packages(alpm_list_t *packages, ...)
This seems the easiest to implement (cut from sync_commit). However, if
we want transaction-independent function, we should do pmsyncpkg_t ->
pmpkg_t conversion always. (Ugly)
3. Then I started to like the following:
alpm_download_package(pmpkg_t *package)
We have a problem with this, in this case if we want to keep the
current "download all packages then check all integrity" order we
should make something like alpm_check_integrity public (no, too
complicated). Alternatively, we could check_integrity in
download_package. This is also logical, but changes the current
behaviour (order).

Either 2. or 3. seems easy first. But there is a very minor thing,
I want to fix, which makes our life more difficult:

delta_path and download_size (of pmpkg_t)

4. First I thought, that these shouldn't belong to pmpkg_t, because they
are not "constant" package properties like packager etc. These depend
on the actual state of the download cache. I started to like the idea of
moving them to pmsyncpkg_t instead. (Btw, alpm_pkg_download_size is in
sync.c) But this just broke my plan to make transaction independent
download stuff, so this idea was dropped.
5. These two fields are computed by compute_download_size as a last
step of sync_prepare. If front-end is allowed to download some packages
manually, then we should update these fields automatically.
(these fields are used by determining the to-be-downloaded files) Even
if we drop "-Sw in front-end" idea, it would nice, if these (or at least
the public download_size) fields were "on-demand" stuffs, like other
fields of pmpkg_t (new infolevel?, or download_size = -1 for "not yet
computed"?): not hardwired sync_prepare computing, and automatically
update the field if needed. (Because the front-end is allowed to request
download_size field between sync_addtarget and sync_prepare etc.)
However, if we want to update these fields after successful download,
we should completely restructure the current download stuff (atm we
just collect files then download them, and forget about packages):-/

I may mixed many things here, and I may misunderstand something
(this delta stuff made things quite complicated in sync.c)

So I decided to rework this download part, but I am unsure about


More information about the pacman-dev mailing list