Finally just installed openSUSE 12.2 x86_64 with GNOME 3.4, and suddenly the software update advise appeared from the bottom bar. So it reminded me that ancient little doubt I had always wondered…
How should I best install software updates? By using that GNOME’s update system, or by disabling all GNOME’s updates and just using the Yast way?
IIRC, Yast way was: applying switch to all repos but Packman, then applying switch to Packman itself, and finally updating packages in @System repo.
If using KDE/Yast-qt just go to software management and all packages in list -> update. If yast-gnome, you can see all the updates with a filter (not sure if there is a way to select them all for update like on yast-qt). Online update on either yast theme only is for official updates I believe so it will not update packman. Otherwise just use zypper up, it should work fine. I would advise against using zypper dup as it ignores vendors I believe. If you test out one of the packagekit programs and they seem to work, then that might be best. This is just some of my personal opinion / wisdom from being a openSUSE user. Hope it helps.
So, GNOME’s update system is called gpk-update or something like that?
Does it download and update the same packages as Yast’s Software Manager, or what’s the difference?
Right now I have set the update preferences to never check for updates, until I’m able to make a decision. It’s just that I don’t want potential software/package conflicts…
Hi
Yes, it’s the desktop applet for updating (hooks into libzypp), so in
essence a fancy GUI for zypper lu/up. You get to decide which one works
for you, me I just use zypper 99.9% of the time…
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop
up 9:42, 3 users, load average: 0.13, 0.14, 0.14
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
Though I prefer using GUIs, I’m not ignorant in console use.
But out of curiosity, could zypper be considered the console equivalent of doing things with Yast?
> Though I prefer using GUIs, I’m not ignorant in console use.
I find out that a daily cronjob which sends the output of “zypper lp/lu”
per email is for me better than every gui and independent from the
actual desktop environment
I did an update with Gnome’s Yast and I think because of the patterns it installed a lot of packages that I didn’t need!Gnome’s Yast is kind of screwy,PackageKit is pretty lame,so I would go with zypper from the command line or read very carefully the modifications made by Yast!
Caf4926, i have switched from KDE to Gnome and i use the interface from Gnome to install updates; i did not encountered any problems at all.
Malcolm, are you sure that it hooks to libzypp? Packagekit comes installed by default too and i guess that Gnome uses Packagekit too.
F_style, each user has a choice of how it gets the updates for his OS. Personally, i use zypper up or zypper lu from a terminal and from time to time zypper dup from console (via ctrl+alt+f1) in runlevel 3 (init 3) to have the latest programs from all the repos that i have added. I use this method since day one of openSUSE and in 6 years i did not encountered problems, well maybe beside connection issues but those where caused by my ISP
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 / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Am 23.09.2012 15:13, schrieb Carlos E. R.:
> On 2012-09-23 08:06, caf4926 wrote:
>>
>> The use of zypper patch in a repo switched environment will cause
>> problems
>
> Why?
>
It does not honor the vendor, there is a bug report on that, I just fail
now to find its number, it will likely not be fixed before 12.3 (that is
off top of my head).
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.2 x86_64 | i3@2.30GHz | 8GB | KDE 4.9.1 | HD 3000
eCAFE 800: oS 12.2 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
On 2012-09-23 16:06, caf4926 wrote:
>
> robin_listas;2489740 Wrote:
>> On 2012-09-23 08:06, caf4926 wrote:
>>>
>>> The use of zypper patch in a repo switched environment will cause
>>> problems
>>
>> Why?
> I sometimes think your comments are made to annoy people.
No, it is a serious question. Honest.
I have no idea why the question pisses you.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 2012-09-23 16:14, Martin Helm wrote:
> Am 23.09.2012 15:13, schrieb Carlos E. R.:
>> On 2012-09-23 08:06, caf4926 wrote:
>>>
>>> The use of zypper patch in a repo switched environment will cause
>>> problems
>>
>> Why?
>>
> It does not honor the vendor, there is a bug report on that, I just fail
> now to find its number, it will likely not be fixed before 12.3 (that is
> off top of my head).
Ah, I see.
Yes, I have had problems when installing packages from one repo and then YOU wanting to
“update” a package. I have to taboo the update. Twice I wrote a bugzilla asking the repo
maintainers to bumb their version numbers a bit so that YOU stopped being noisy, and once they
did just that.
I just did not relate the problem with vendor changes.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)