Mailinglist Archive: opensuse-factory (753 mails)

< Previous Next >
Re: [opensuse-factory] Help Apper to survive (12.2)
Le mardi 21 août 2012, à 18:26 -0500, Rajko a écrit :
Also, from whole thread is clear that whoever is busy with fixing and
promoting current breed of simple package management will do great
favor to community with some half technical introduction in a whole
system, so that helpers on the mail lists and forums finally can tell
something else then "remove it" as a cure to the problems.

I thought we already had a few mails with such an intro, but maybe that
was not enough, so here's an attempt.

The global architecture looks like this:

frontend (UI) -> PackageKit -> PackageKit zypp backend -> libzypp -> rpm

I assume we don't care much about the "libzypp -> rpm" part, since it's
pretty low-level.

So we have a frontend:
- This can be apper, pk-update-icon, or the update plugin in
gnome-settings-daemon.
- This frontend generally has a UI, but can also be UI-less (for
instance, when the update plugin in GNOME looks if there's an
update, there's no UI displayed).
- The frontend will use dbus to talk to PackageKit. If PackageKit is
not running, then it will automatically start the PackageKit daemon.
- Usually, those frontends would only wake up the PackageKit daemon
once a day, unless there's an explicit action from the user (like
using the frontend to install a package). If the frontends ping
PackageKit more than that, then it's usually a bug in the frontend.
- There might be options to configure the frontends (gpk-prefs in
GNOME, for instance).
- For the "update icons" (generic name for different things in all the
desktops), we usually need a process that is always running in the
user session. pk-update-icon is a good and simple example of this.
You can usually disable this process somehow. For instance, in XFCE,
you simple remove the autostart for pk-update-icon. In GNOME, you
disable the update plugin of gnome-settings-daemon (it's a gsettings
key). Disabling those icons means that PackageKit will never be
started, unless there's a direction from the user via a frontend.

Then we have PackageKit:
- It's a daemon offering an abstraction layer over dbus of the
packaging system, so that it offers the same dbus API on all
systems, even though people might be using different packaging
systems (rpm vs deb, but also yum vs zypp).
- Several applications can talk to the PackageKit daemon at the same
time because it centralizes all the requests to the packaging
system.
- Note that the PackageKit daemon is /usr/lib/packagekitd.
- There are different configuration options, see files in
/etc/PackageKit/ (PackageKit.conf, mostly).
- On openSUSE, the PackageKit daemon exits after being idle for 15
seconds (option in PackageKit.conf). So usually, the PackageKit
daemon is not running.
- The daemon uses a backend to talk to the packaging system. In
openSUSE, this is the zypp backend. PackageKit itself is usually
fine, issues are generally in the backend.

Then we have the zypp backend in PackageKit:
- This is the small code that enables PackageKit to work in openSUSE
by using libzypp. This makes PackageKit generally behave like other
libzypp-based tools (zypper, yast, etc.).
- As libzypp is using a lock to avoid multiple applications doing zypp
stuff at the same time, the zypp backend can block zypper/yast/etc.
This is the same thing as zypper blocking the yast tool, or yast
blocking zypper.
- Knowledge of the libzypp API is useful to help with the code.
- Unfortunately, there is no one actively working on this backend, and
the current code is suboptimal/buggy in various places, it seems.
But bug fixes are going in every now and then.
- I've seen in a bug comment that a rewrite is planned.
- Bugs like "this package should not have been installed during an
update" usually come from the zypp backend.

And then we have libzypp. I don't know much about it, except that there
the lock I've mentioned above.

Does this help a bit?

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >