Hi Roman ;-),

I've talked the PackageKit developers, and they agreed to drop the ALPM backend, creating a "pacman" backend instead. ALPM is way too low level for the implementation PackageKit needs.

This means, that the backend for pacman in PackageKit will also take care of configuration handling (pacman.conf, mirrorlist etc).

You're right. "GetDistroUpgrades" won't fit arch very well. What this function will do in ALPM is undecided yet. Either, not being implemented (or another information about rolling releases), or implement it as a redirect to GetUpgrades (this will be rather up to the PK developers).

The current plan for the pacman backend in PackageKit:
1.) Reading the config file by default (on every call probably, or saved in a internal structure - undecided).

2.) Implementing the function RepoSetData/backend_repo_set_data, checking against this pacman config, and if necessary re-write the pacman configuration. This function will need it's own logics, since neither pacman (no library) or alpm support this.

3.) Using the read / configured parameters of the configuration (#1) to supply ALPM with the information it needs.

The way for RepoSetData:
RepoSetData("options", "IgnorePkg", "one two three");
RepoSetData("core", "Server", "http://yet-another-server.com");
RepoSetData("extra", "Include", "/path/to/file");
RepoSetData("community", "Mirror", "http://yet-a-new-mirro-for-mirrorlist.com/to/be/used");

This is the basic step to just get the possibility for a complete backend.

The main reason for reading / parsing and editing pacmans configuration is, that the PackageKit devs expect that the backend library handles the configuration. I personally thing that it's good that alpm does not rely on any configuration files, but many things in the world are different to what i'd like them to be:D.

---
The API stuff:
If you look at the signal "UpdateDetail", you'll find "obsoletes" and "updates" in example. This (for the alpm interface) provides a list of packages to upgrade (or install as a dependency), and packages which became obsolete.

In general, I think as much "distro specific" things which can find a solution in the backend will find their solution in the backend.
Replaces: handle the replaces in the alpm / pacman backend. I don't think PackageKit really cares about what is replaced - but we can ask if they do :D. Currently, there is no working implementation for replaces which I know (APT throws conflicts on replaces if I read the code correctly).
Confclits: The current "conflict" handling is throwing an error (PK_ERROR_ENUM_FILE_CONFLICTS).

The PackageKit developers are open for talks. Allthough, they don't know too much about ALPM or pacman in general. I already gave a short introduction (on their lists) about how alpm/pacman works, not very detailed though.

Implementing a "pacman config reading" is the way to start (I think) to have at least all necessary information required for alpm.
Then we can still worrie about the single functionalities (i'm sure, there will be enough of those worries :D).

Kind regards,
Georg