[pacman-dev] ALPM & PackageKit

[Georg Grabler]

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

On Tue, Sep 2, 2008 at 10:32 PM, Roman Kyrylych <roman.kyrylych at gmail.com>wrote:

> 2008/9/2 Georg Grabler <ggrabler at gmail.com>:
> > Hey guys,
> >
> > I've some concerns. I also posted quite a similar thing to the dev~ list
> of
> > PackageKit, and I'll also try to get some information in IRC lateron.
> >
> > First of all, as you might know, the Shaman devs (drf and boom) would
> like
> > to switch to packagekit with version 2 of Shaman.
>
> Is it their updated plan?
> (It is said that there will still be packagekit, alpm, aur and abs
> backends here:
> http://shaman.iskrembilen.com/trac/wiki/Todo )
>
> >
> > Therefore, I looked at the implementation of the ALPM backend in
> PackageKit
> > (developed by onestep).
>
> OMG! He's Ukrainian and we even met during our community meeting in 2007.
> The Internet is so small. :-D
>
> > As it seems, all operations which at least require a synchronisation, or
> > download functionality, are missing in the backend implementation.
> >
> > The reason:
> > PackageKit has no functionality to supply server or configuration
> parameters
> > to the backend library (interfaces missing).
> >
> > Now, since ALPM does not read any config files (I basically think it's
> the
> > right way that the frontends have their own config management), I'd like
> to
> > know before I talk again with the PK maintainers what ALPM would need for
> > all "standard" operations (see chart at
> > http://www.packagekit.org/pk-matrix.html).
>
> Honestly, I think PackageKit is not very suited for a distro like Arch.
> IMHO it's not very generic and is oriented for fixed-release-based
> distros like Debian/Ubuntu/Fedora/SUSE/etc.,
> but not for distros like Arch or Gentoo,
> e.g. what GetDistroUpgrades is supposed to mean in Arch? :-)
> and for me it looks like PackageKit API is missing some stuff that
> pacman/alpm provides
> (e.g. how can a frontend to PackageKit easily display a list of orphans?,
> and how about conflicts/replaces?)
> (I didn't go through API details deeply, so correct me if I'm wrong).
> Are PackageKit devs open to improvements that would allow it to be
> more suitable for Arch?
>
> --
> Roman Kyrylych (Роман Кирилич)
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20080903/46ec8db2/attachment.htm>