Automatic Updates - Is Apper as useless as Packageit was?

English Applications
1

After a week or so after my upgrade from 11.3 > 12.1,

I’ve again found that there is no substitution for “zypper up” – Whenever I use zypper, it still consistently finds packages that need updating that the official “automatic” updaters don’t.

Zypper updates <everything> that’s on the system, why couldn’t Packagekit and now Apper perform to that level?

IMO nothing less should be expected from an automatic updater than inspecting and maintaining <everything> on the system, or is that opinion somehow faulty? And, considering how well zypper maintains and updates all packages on the system, is there a reason why it isn’t <the> official updater?

TS

2

On 2012-03-01 03:46, tsu2 wrote:

> IMO nothing less should be expected from an automatic updater than
> inspecting and maintaining <everything> on the system, or is that
> opinion somehow faulty? And, considering how well zypper maintains and
> updates all packages on the system, is there a reason why it isn’t <the>
> official updater?

Hum, no, I would not expect more from those updaters than the equivalent to
a zypper patch, not a zypper up.

And as to why zypper is not the default one, well, it is up to you to use
it, but these new apps intend that the plain user can run the update if the
task is delegated from root, without having to use the root password (using
policy kit, I think). Zypper can not do that unless you configure sudo in a
certain way which is not the default way.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

3

On 03/01/2012 03:46 AM, tsu2 wrote:
> IMO nothing less should be expected from an automatic updater than
> inspecting and maintaining <everything> on the system, or is that
> opinion somehow faulty?

there are many situations and circumstances where an administrator would
not wish to constantly be changing <everything> available to be changed!

for example, there are people, situations, workplaces etc which can
thrive only with a system which is stable, predictable, reliable and
secure…

now, maybe that does not describe your individual needs or how you
want your system to be…but, it certainly describes many folks’ desire
on their daily driver…you know, the one they depend on at school, or
work, or maybe they just depend on to be usable when the wanna call Aunt
Tillie on Skype…or wanna jump into WoW for a few days of fun…

so, the YaST Online Updater was years ago tuned up to NOT change every
possible thing that can be changed…but, rather to only change those
things the developers place in one repo, the update repo…where are
placed security patches and major bug fixes…only.

ymmv, but it has been my experience over the years that using only YaST
Online Update, while having only four repos enabled (oss, non-oss,
update and packman) usually results in a stable machine…

unfortunately though it seems the further away we get from SuSE 9 the
less stable is the system…(but, that is a different thread)

so, the zypper equal to YaST Online Update is “zypper patch” and not the
potential stability killer “zypper up”…now, there is absolutely
nothing wrong with “zypper up” if you have been thoughtful and
responsible with the repos enabled and refreshed…but, if you have not
paid attention there then a “zypper up” (or “switch vendor” in YaST
Software Manager) is kinda like putting a bullet in the gun, spinning
the cylinder and pulling the trigger . . .

so, to answer your question: no, your opinion is not faulty for
you…and, my opinion is not faulty for me…but, you should understand
that your opinion does not fit all situations and all machines…

and i really really hope ‘they’ never make so that everytime any Linux
developer anywhere commits new code to his/her stable tree that my
system changes if i run its “automatic updater”!!

–
DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

4

DenverD wrote:

> paid attention there then a “zypper up” (or “switch vendor” in YaST
> Software Manager) is kinda like putting a bullet in the gun, spinning
> the cylinder and pulling the trigger . . .

‘zypper up’ does not allow vendor change.
‘zypper dup’ does.

Vahis

http://waxborg.servepics.com
openSUSE 11.4 (x86_64) 2.6.37.6-0.11-default main host
openSUSE 12.1 (x86_64) 3.2.7-9-desktop Tumbleweed in VirtualBox
openSUSE 12.1 (i586) 3.1.9-1.4-desktop in EeePC 900

5

On 03/01/2012 05:07 PM, Vahis wrote:
> ‘zypper up’ does not allow vendor change.
> ‘zypper dup’ does.

thanks…and, glad to see you here…

–
DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

6

Thx all for the inputs.
And, if my language “useless” is a bit much, I apologize since Apper’s really not useless particularly if it does exactly what it’s designed to do.

That’s interesting to me that apper and packagekit behave as they do by design.

  1. Re: zypper up and vendor change issue, this is from the zypper man pages
   update (up) [options] [packagename] ...
          Update installed packages with newer versions, where possible.

          This command will not update packages which would require  change  of  package
          vendor  unless  the vendor is specified in /etc/zypp/vendors.d, or which would
          require manual resolution of problems with dependencies. Such  non-installable
          updates will then be listed in separate section of the summary as "The follow-
          ing package updates will NOT be installed:".

          To update individual packages, specify one or more package names. You can  use
          the  '*'  and '?' wildcard characters in the package names to specify multiple
          packages matching the pattern.

So, it seems that zypper up will not update a package given various possible reasons, and one reason is when there is a vendor change and is not explicitly listed for updating (in vendors.d).

  1. I spent some time considering reasons for updating and patching instead of updating, and although I cannot find an explicit definition for each anywhere (including the MAN pages), I assume that “updating” means replacing with a newer version whereas patching means maintaining the existing version of a package.

Although a case can easily be made for simply patching and not updating, I strongly feel that today the default behavior should be to update all for the following reasons:

  • As fast as vulnerabilities and exploits appear nowadays, it’s usually safer to utilize the latest which oftentimes means removing and adding features, not just plugging holes. Yes, sometimes it’s safer or required to lock a specific version, but those situations should be the exceptions, not the rule… And, if you find yourself in this situation it’s a strong warning to expect some kind of EOL.

  • For the majority of less sophisticated users, ie Home Users, Hobbyists, newbies migrating from Windows, etc., they should expect a system as secure and functional as possible by default, so updating <everything> should be expected and be the default so that the application or components are of latest design. Yes, this seems to put a high burden on getting dependencies correct, but isn’t this generally the case?

  • It seems that both updating and patching don’t have an easy way to roll back changes, probably requiring a manual uninstall followed by re-install specifying a legacy version, so there doesn’t seem to be an advantage to either if a change has to be undone. As to how much more risky an update is compared to a patch, it’s difficult to hazard a guess considering that updates are supposed to be stable by default. BTW - if this really true, I hope that some kind of rollback is in a roadmap.

In the meantime, because proper patching and updating is critical to both system performance and security, IMO Users should be at least explicitly educated on their options, particularly if the default behavior only addresses most basic system patches and does nothing to ensure the integrity of applications they have installed… leaving massive potential security and performance issues if unaddressed.

If this kind of decision (to apply updates by default) is too momentous a decision, I’d suggest that the User should still be offered an option to configure for updates or patching(include a description of each option), and better yet to track that User decision and whether it causes unexpected problems later or not. I’d guess that this wouldn’t take more than a very few lines of relatively simple code, particularly if the underlying engines are already proven and reliable.

IMHO,
TS

7

On 03/02/2012 11:16 PM, tsu2 wrote:
> Apper’s really not useless particularly if it does exactly what it’s designed to
> do.

Apper is a KDE product which conflicts with YaST/Zypper…how it works
with apt or yum i have no idea…

do not use apper on openSUSE–disable it or uninstall it.

of course, all are free to ignore that advice…just be prepared to fix
your messed up system…sooner or later.

–
DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

8

On 2012-03-02 23:16, tsu2 wrote:
> Although a case can easily be made for simply patching and not
> updating, I strongly feel that today the default behavior should be to
> update all for the following reasons:
>
> - As fast as vulnerabilities and exploits appear nowadays, it’s usually
> safer to utilize the latest which oftentimes means removing and adding
> features, not just plugging holes. Yes, sometimes it’s safer or required
> to lock a specific version, but those situations should be the
> exceptions, not the rule… And, if you find yourself in this situation
> it’s a strong warning to expect some kind of EOL.

Mmmm.

In openSUSE parlance, patching is what is done via the updates repo. Here
all security issues are solved, doing whatever necessary, keeping the same
version if possible, which guarantees the greatest chance of succes by
minimal alteration to the system. Meaning, replacing with a new version
often brings untested situations and greater chances of failures.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

9

And I would agree if stability is given a much higher priority over security which would generally be the case for example if you’re running a custom built application that relies on specific library functionality. If a new version removes some functionality that’s critical to your application, then you must patch and should not upgrade.

On the other hand, libraries generally don’t remove functionality without good reason… They recognize that applications rely on the functionality those libraries provide, so removal or changing the way the library functions is a momentous decision, so normally that happens only when its dependencies significantly change or an exploit is discovered that cannot be simply patched.

For a great majority of the world, these “significant” changes that libraries make from one version to another won’t change the main functionality and therefore won’t typically break anything so it’s a big advantage for <most> Users to update rather than patch.

So, IMHO I’d still suggest that

  1. For both patching and upgrading, changes should be journaled and a simple one-click if not automatic rollback be possible.
  2. The User should be educated about what an update and what a patch is, and be given his choice.
  3. Maybe not the most conservative decision, but I feel that it’s more likely that the more advanced, technically oriented User might choose patching over updating, for the majority of Desktop Users updating is much more likely appropriate.

IMO,
TS

10

On 2012-03-07 01:46, tsu2 wrote:

>> In openSUSE parlance, patching is what is done via the updates repo.
>> Here all security issues are solved, doing whatever necessary, keeping the
>> same version if possible, which guarantees the greatest chance of succes by
>> minimal alteration to the system. Meaning, replacing with a new version
>> often brings untested situations and greater chances of failures.

> And I would agree if stability is given a much higher priority over
> security which would generally be the case for example if you’re running
> a custom built application that relies on specific library
> functionality. If a new version removes some functionality that’s
> critical to your application, then you must patch and should not
> upgrade.

You don’t understand.

The patches supplied by openSUSE aim at maximum security with the minimal
modification to the system, thus ensuring the same level of stability the
original distribution had. No new features, no new versions. It is the
traditional SUSE method.

You can of course discard this system and use updates instead. Get new
versions of programs and libraries. It is your choice. But these updates do
not get the same level of testing, things can and do break.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

11

Hi and thanks for an interesting thread. My question is why do I sometimes get a notification to update from apper which is not shown as required if I use Yast online update?
Budgie2

12

It could be because apper is still enabled in the system-settings
service manager startup services

13

On 2012-03-08 00:56, Budgie2 wrote:
>
> Hi and thanks for an interesting thread. My question is why do I
> sometimes get a notification to update from apper which is not shown as
> required if I use Yast online update?

Because YOU only shows updates from the update repo.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

14

If apper conflicts with zypper, YaST conflicts with zypper as well, as you can only run one of them at the same time. Conclusion, your claim is wrong. Even more so since apper is just a frontend to packagekit and packagekit uses zypper as backend. I hope you can do the maths…

Most issues people have with apper are acutally zypp backend bugs. Sorry to destroy the illusion.

15

On 2012-03-09 01:06, rabauke wrote:
> Most issues people have with apper are acutally zypp backend bugs.

No, they are packagekit bugs.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

16

Hm, should I believe you or the people at openSUSE actually working on the zypper, packagekit and apper code? I guess the answer is obvious. A little learning is a dangerous thing.

17

If that had been true then I (and others) would not have been able to resolve the problem simply by using Yast and/or zypper instead of apper/packagekit. I note that many others have reported the same result on this forum.

for example on 25/02/12 07:56, caf4926 wrote:

To read other similar comments you might wish to go here or simply do a search of the forums for “packagekit”

I’m sorry to destroy your illusion.

18

To repeat myself: A little learning is a dangerous thing. If you do not even know that packagkit uses a zypp backend, well…

19

On 2012-03-09 13:46, rabauke wrote:
>
> robin_listas;2446985 Wrote:
>> On 2012-03-09 01:06, rabauke wrote:
>>> Most issues people have with apper are acutally zypp backend bugs.
>>
>> No, they are packagekit bugs.
>>
>
> Hm, should I believe you or the people at openSUSE actually working on
> the zypper, packagekit and apper code? I guess the answer is obvious. A
> little learning is a dangerous thing.

The suse devs said they were packagekit bugs, so I believe them.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

20

YaST Package Management Modules -> libzypp
zypper -> libzypp
Apper -> PackageKit -> PackageKit zypp backend -> libzypp

And the YaST team says the fault is in the “PackageKit zypp backend” (and a little part in libzypp) and not in Apper or PackageKit (Re: [opensuse-factory] packagekit still in 12.1? 12.2).