February 19, 2008

Third party updates

James since your blog doesn’t appear to support comments I’ll stoop to “discussion by blog”.

You state that third party repositories are not considered by the updater tools (YaST Online Update,Updater applet, zypper). This is not really true. In fact, by default the tools will only notify you of updates that are patches (higher priority than newer versions of packages). These patches could be in any repository, in practice they are only used in the official update repository. There is some more information about how patches are specified on the wiki .

Now, while only these “patches” are considered important enough to notify the user of, and apply automatically, other repositories are considered while performing the updates. This means that in the case of a new kernel patch being released which is incompatable with the currently installed nvidia driver, the kernel patch will not be installed until there are updated nvidia drivers available in the nvidia repository that will work with the new kernel. Once there is a new nvidia driver available the update will install and will pull in the updated nvidia driver from the other repository as a dependency automatically. The same should happen with madwifi, though they were quite slow in making new drivers available for the recent kernel updates, if it does not then it’s probably a packaging issue. There is more information about kernel module dependencies in this paper.

Furthermore, if you wish to be notified of new versions of packages in any repository, as well as patches, you can be. Simply tick the “Show upgrades” tickbox in the updater.

You can also do this with zypper

zypper up -t package

(That’s a literal “package” , not a package name)

This is not enabled by default as just because a user has a repository available in his or her package manager it does not mean that he or she necessarily wishes to install newer versions of packages just because they are there. For example packman repository has had problematic alsa upgrades in the not too distant past, which most people do not want. There is also the issue of “vendor bouncing” where a newer version of a package becomes available in one repository, and then in another, and so on. There are other ways to resolve that though, such as vendor sticky (Assuming the user wishes to stay with upgrades & updates from the same vendor, unless he or she specifically installs one from another vendor).

- 3 comments by 1 or more people Not publicly viewable

  1. Me

    From someone that doesn’t uses libzypp…

    - “This is not enabled by default as just because a user has a repository available in his or her package manager it does not mean that he or she necessarily wishes to install newer versions of packages just because they are there.”
    But if a user installed from an OBS repository, he for sure wants updates of that package from that repository. Even if these updates aren’t “patches”. Are the tools doing this by default?
    - From man zypper: “-t,—type Type of resolvable (default: package)”
    So I can’t use packages and patches at the same time? That’s bad.
    And is the man incorrect? Are you saying that patches is the default?

    I think that libzypp needs a priority system, like Smart. And the “vendor sticky” should be configurable…
    - Disable sticky
    - Set vendor sticky
    - Set repository sticky
    - ...

    Anyway openSUSE tools still have more problems.
    - YaST has a “Reset Ignored Dependency Conflicts”
    With Smart I don’t need toignore dependecy conflicts. Is YaST that sometimes finds conflicts where they aren’t. And if it is going to be such a list… there must be a way to see it and remove a single element. All or nothing isn’t a good solution.
    Also is this list YaST specific or all libzypp tools use it? (and is such information available somewhere?) If zypper uses the list, there is a way to handle it I don’t see any such option in the man. There is not even a “Reset Ignored Dependency Conflicts” equivalent.

    I don’t think that openSUSE 10.3 package management stack is useful. Not for new user, and neither for power users. New users will not have what they need, and power users are better using Smart.
    And the day Smart adds the vendor/repository sticky option it probably will be a better option also for new users.

    19 Feb 2008, 21:15

  2. Adapco

    I disagree with the above post. SuSE 9.1, 10.0, 10.1, and 10.2 had update systems that left a lot be desired. I exclusively used Smart during that time. Sometimes I had problems with the Smart channel file getting corrupted or Smart updating my system and breaking dependencies. I was rather adroit at the command line, but never got the hang of the GUI. In 10.3, zypper is much easier. No, it does not have all of the options of Smart, but it is easier. It is a huge improvement and I disagree that new users or power users would refrain from using zypper. Actually, most new users would find zypper to be a boon.

    I also disdain the term “power user”. It is often used when the person has no idea what it truly means.

    25 Feb 2008, 20:13

  3. @”Me”

    -t package means package or higher priority, so will include patches as well.

    The build service doesn’t support adding patches to repositories yet. New versions of packages are not the same as patches though.

    As for solver issues in zypp, hopefully these will be a thing of the past with the new solver in factory. You mention that YaST sometimes reports conflicts where smart does not – in some cases this is a problem with smart not understanding the conflict and it can do the wrong thing.


    I assume you were referring to the other comment, as you don’t seem to disagree with anything I said.

    25 Feb 2008, 21:02

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

February 2008

Mo Tu We Th Fr Sa Su
Jan |  Today  | Mar
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29      

Search this blog



Most recent comments

  • Hey skx, how do you do that ? I run into the fu….. problem, that curl terminate with unspec. error… by David on this entry
  • With some minor changes this will also work for updating from 11.0 to 11.1. by skx on this entry
  • You are the man!!! Great work and good documentation! It worked without any problem for me. Thanks a… by Vany on this entry
  • didn't work for me. In fact killed the system. Have to download 11.0 and burn to dvd to fix it. by maybe windows on this entry
  • Will this method work for 11 => 11.1 ? by Erik Jakobsen on this entry

Blog archive

Not signed in
Sign in

Powered by BlogBuilder