ZYPPER: a) cross-repo package dependencies and b) package type "application"

michael_of · February 19, 2018, 4:38pm

Hi all,

I’ve had some hard-to-understand zypper issues recently. At first, the KDE Plasma “Software Updates” plasmoid started to show update errors because of unresolvable package dependencies. Same then in in bash, with zypper, but not comprehensable why. “sudo zypper update -t patch” failed for a docker package, starting yast and manually (!) select the newer version available from the resp. OpenSuse update repo worked fine. Whyever…

Chatting in #suse put me into the direction that the issue probably came from my “repo landscape”, which is the following:

$> LC_ALL=C zypper lr -d 
Repository priorities in effect:                                                                                                                  (See 'zypper lr -P' for details)
      20 (raised priority)  :  1 repository  
      99 (default priority) :  7 repositories
     120 (lowered priority) :  2 repositories                                                                                                                                     
     130 (lowered priority) :  1 repository                                                                                                                                       
                                                                                                                                                                                  
#  | Alias                               | Name                          | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                                  | Service                                                                                                                                       
---+-------------------------------------+-------------------------------+---------+-----------+---------+----------+--------+--------------------------------------------------------------------------------------+--------                                                                                                                                       
 1 | homeSauerland42.3                   | homeSauerland42.3             | Yes     | (r ) Yes  | Yes     |  120     | rpm-md | http://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.3/        |                                                                                                                                               
 2 | homeSauerlandUpdate42.3             | homeSauerlandUpdate42.3       | Yes     | (r ) Yes  | Yes     |  120     | rpm-md | http://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.3_Update/ |                                                                                                                                               
 3 | http-download.opensuse.org-171beb23 | home:ecsos                    | Yes     | (r ) Yes  | Yes     |  130     | rpm-md | http://download.opensuse.org/repositories/home:/ecsos/openSUSE_Leap_42.3/            |        
 4 | http-download.opensuse.org-af03eba6 | openSUSE:Leap:42.3:Update     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/openSUSE:/Leap:/42.3:/Update/standard/     |        
 5 | mozilla/Leap42.3                    | mozilla/Leap42.3              | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_42.3                 |        
 6 | packman                             | packman                       | Yes     | (r ) Yes  | Yes     |   20     | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.3/                   |        
 7 | repo-42.3-non-oss                   | openSUSE-42.3 Non-OSS         | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.3/repo/non-oss/                    |        
 8 | repo-42.3-oss                       | openSUSE-42.3 OSS             | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.3/repo/oss/                        |        
 9 | repo-42.3-update-non-oss            | openSUSE-42.3 Updates Non-OSS | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/42.3/non-oss/                               |        
10 | repo-42.3-update-oss                | openSUSE-42.3 Updates OSS     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/42.3/oss                                    |        
11 | skype-stable                        | skype (stable)                | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | https://repo.skype.com/rpm/stable/

OF COURSE I’m trying to avoid “unstable” home:… repos whenever possible. But if I specificly need a package not available from std repos, I’m searching for “trustworthy” repos. And I strongly believe that Sauerland and Ecsos are trustworthy

To keep the impact from these other repos as small as possible, I’ve lowered their priority by setting it to a higher value than the usual 99.

Usually works fine, except these last mystic cross-dep errors, which I was good-luck able to solve.

But there are two questions left, which I don’t understand:

I really want to know why “zypper search -i -r homeSauerland42.3” on my 42.3 box lists “Bluefish” as “i” application from repo homeSauerland42.3. ALTHOUGH there seems to be not a single “Bluefish” pkg installed from repo homeSauerland42.3? Confused …

$> LC_ALL=c zypper info -t application --requires Bluefish
Loading repository data...
Reading installed packages...


Information for application Bluefish:
-------------------------------------
Repository  : openSUSE:Leap:42.3:Update                                 
Name        : Bluefish                                                  
Version     :                                                           
Arch        : noarch                                                    
Vendor      :                                                           
Summary     : Text editor with many web and software development extra's
Description :                                                           
    Bluefish is a powerful editor targeted towards programmers and web developers, with many options to write websites, scripts and programming code. Bluefish supports many
    programming and markup languages and has many features, but is still a very fast and lightweight application.

    A selection of the features:

    If you are an occasional coder who is in need for a simple to learn editor, or a heavy coder who dislikes heavy IDE's like eclipse or netbeans, Bluefish is your editor of
    choice!

      - Well done syntax highlighting which for example supports languages inside languages (e.g. Javascript inside HTML inside PHP)
      - All kind of powerful editor features like auto indenting and auto completion for many functions and libraries in many programming languages
      - Project support
      - Support for remote files over ftp, sftp, webdav, etc
      - Powerful search and replace engine
      - Customizable integration of external programs such as lint, make, etc
      - Snippets plugin to automate often used code
      - Code-aware in-line spell checking
      - Zencoding or Emmet support
      - Bookmarks panel
Requires    : bluefish                  

$> LC_ALL=C zypper search -i -r homeSauerland42.3
Loading repository data...
Reading installed packages...

S  | Name     | Summary                                                    | Type       
---+----------+------------------------------------------------------------+------------
i  | Bluefish | Text editor with many web and software development extra's | application
i+ | davfs2   | FUSE-Filesystem to access WebDAV servers                   | package    

$> LC_ALL=C zypper search -s Bluefish
Repository 'packman' is out-of-date. You can run 'zypper refresh' as root to update it.
Loading repository data...
Reading installed packages...

S  | Name     | Type        | Version     | Arch   | Repository               
---+----------+-------------+-------------+--------+--------------------------
i  | Bluefish | application |             | noarch | openSUSE:Leap:42.3:Update
i  | Bluefish | application |             | noarch | openSUSE-42.3 OSS        
i  | Bluefish | application |             | noarch | openSUSE-42.3 Updates OSS
i  | Bluefish | application |             | noarch | homeSauerland42.3        
   | bluefish | srcpackage  | 2.2.10-7.1  | noarch | openSUSE:Leap:42.3:Update
   | bluefish | srcpackage  | 2.2.10-7.1  | noarch | openSUSE-42.3 Updates OSS
   | bluefish | srcpackage  | 2.2.10-27.2 | noarch | homeSauerland42.3        
i+ | bluefish | package     | 2.2.10-7.1  | x86_64 | openSUSE:Leap:42.3:Update
i+ | bluefish | package     | 2.2.10-7.1  | x86_64 | openSUSE-42.3 Updates OSS                                                                                                    
v  | bluefish | package     | 2.2.7-5.3   | x86_64 | openSUSE-42.3 OSS                                                                                                            
v  | bluefish | package     | 2.2.10-27.2 | x86_64 | homeSauerland42.3

Second question is more general, about dependencies and repos.

As said, I’ve set the home:… priority to 120. Now I’ve recognized the following thing: E.g. pkgB from repoB needs pkg1 as dependency. pkg1 is not available in OpenSuse std repos, but in repoB and also in repoA. It seems, that zypper takes dependency “pkg1” from first found repo, respecting priority first, but repo sort order or whatever as second criteria.

This leads or at least could lead to unwanted “cross-repo” dependencies. E.g. if “pkg1” is taken by zypper from repoA although it would be available in repoB, I can’t drop repoA anymore, even if the reason for adding repoB might be obsolete in future.

Is there any way to “stick” a dependency to the repo where the pkg belongs which needs the dependency? A “Try to resolve from same repo first” - option for zypper?

Thanks in advance,
Michael

dcurtisfra · February 19, 2018, 6:39pm

How many specifically needed packages which are not available from the standard repositories, do you actually need?

michael_of · February 19, 2018, 9:13pm

dcurtisfra,

for my 42.3 at home e.g. I need:

DAVFS2
Mediathekview
Musescore
qwinff

and Skype.

Some more for my 42.3 VPS. Mostly PHP based pkgs from server:php:applications.repo, which are also not existing in standard repos. Or, e.g. TYPO3, are outdated for many, many years.

dcurtisfra · February 20, 2018, 1:16pm

davfs2 is available from the Filesystems repository: <http://download.opensuse.org/repositories/filesystems/openSUSE_Leap_42.3/>.
AFAICS “MediathekView” is a Java application and therefore, it can be installed within your user directory space and executed from there; IOW it doesn’t really need a “system-wide installation” in, for example, “/opt/”.

The openSUSE package search is currently broken – I can’t find “MediethekView” in any of the Multimedia repositories – it may be in a private build area.

MuseScore is available for LEap 42.3 from the following Multimedia repository: <http://download.opensuse.org/repositories/multimedia:/musescore2/openSUSE_Leap_42.3/>.
QWinFF is written in Qt4/C++ and therefore only runs under KDE Plasma 5 in compatibility mode.

Ditto, broken openSUSE package search.

The openSUSE Wiki entry for Skype <https://en.opensuse.org/Skype> points to Skype’s official RPM repository: <https://repo.skype.com/rpm/stable/> – the Wiki text hasn’t been updated: the newest Skype (for Linux) version available is 8.15 – but that’s what you should be seeing in the Skype repository you’ve defined.

Yes, for the case of TYPO3, the openSUSE Build Service PHP Applications does contain a rather outdated version but, that’s possibly due to no-one wanting to maintain that project in the Build Service – you may have to use the TYPO3 PHP code from the .org website – it is normally simply installed in a sub-directory of “/srv/” but, there are some configuration changes to be made to the Apache Web Server.
[HR][/HR]A suggestion to alleviate the package dependencies issues you’re experiencing:

Revert to the list of repositories which the Leap 42.3 installation defines; add the Packman and Skype repositories.
Add the Filesystems and Multimedia MuseScore2 repositories I’ve mentioned above.
Wait for the openSUSE Package search to be repaired and then, add the distribution repositories for MediathekView and QWinFF.

michael_of · February 22, 2018, 7:08pm

dcurtisfra, thank you for answering so detailed!

As you’re suggesting repo “filesystems” to be preferred instead of my selected repo home:Sauerland, it seems that you have the knowledge that this repo is more “in-line” with the distribution. Maybe my lack of knowledge, if not, it would be cool to have this documented somewhere, as I would NEVER have expected this, I’ve assumed the opposite: When e.g. searching for DAVFS2 on https://software.opensuse.org (which is online again), it lists only (!!!) “potential unstable packages” for davfs2. 4 home:… repos, and “filesystems”. I needed Sauerland’s repos long before DAVFS to circumvent a bug with my NIC, this bug was somewhat painful on each dist upgrade since 13.1. So knowing from #suse that Sauerland’s repos are trustworthy, knowing from chatting with Sauerland about the home:… naming convention, my unchecked assumption for repo “filesystems” was that this repo might be from “whoever”, NOT following the home:… naming convention

So my resulting question for this is: Is the rule/naming convention for repos listed on https://software.opensuse.org that each repo NOT starting with “home:…” could be seen as stable, also shown as “potential unstable”? Or are the any other criteria?

Again thank you for spending so much time for each of my packages.

What you’re saying is for sure correct, but from my point of view I’m the “lazy” guy, that’s why I love existing packages, if available. Seriously: I’ve learned a lot about IMHO good practices for installations on OpenSuse from installed packages, looking at their READMEs and list of files and their location. Simple example: my experience was, esp. for PHP-based applications like e.g. Nextcloud, that existing packages are more aligned to OpenSuse than just “throwing” an archive below a webroot. For TYPO3 I must to do this, but for Nextcloud I’ve switched back to pkgs from server.php:applications, which are available mostly at the same day Nexcloud announces a new stable release, bloody cool. The Nexcloud package itself is not rocket science, it’s the Nextcloud archive, readmes on /usr/share/doc and a conf file for apache, /etc/apache2/conf.d/nextcloud.conf. And exaxctly these .conf files made my life easier when starting with apache, as the file layout on OpenSuse is somewhat different than on other distros.

But even when switching to “filesystems” and “multimedia” repos, my initial questions are still unanswered. Currently both my 42.3 box at home and my VPS are working completely fine, so I don’t have a current issue with the cross-repo dependencies or the incorrectly shown “application” package Bluefish. It’s just that I want to understand WHY zypper shows Bluefish as dependency, maybe there’s good reason for it, but i can’t understand. Same for my second question about how zypper resolves dependencies from repos with same priority, if “first in sort order” is the (only) way it works, or if you can set it somehow.

Additional question:

As I’m loving and using TYPO3, and as seen for Nextcloud it’s not rocket science to create a package for this PHP-based apps, maybe I could “maintain that project in the Build Service”? Any hints how/who to ask?

dcurtisfra · February 23, 2018, 11:21am

michael_of:

As you’re suggesting repo “filesystems” to be preferred instead of my selected repo home:Sauerland, it seems that you have the knowledge that this repo is more “in-line” with the distribution. Maybe my lack of knowledge, if not, it would be cool to have this documented somewhere, as I would NEVER have expected this, I’ve assumed the opposite: When e.g. searching for DAVFS2 on https://software.opensuse.org (which is online again), it lists only (!!!) “potential unstable packages” for davfs2. 4 home:… repos, and “filesystems”. I needed Sauerland’s repos long before DAVFS to circumvent a bug with my NIC, this bug was somewhat painful on each dist upgrade since 13.1. So knowing from #suse that Sauerland’s repos are trustworthy, knowing from chatting with Sauerland about the home:… naming convention, my unchecked assumption for repo “filesystems” was that this repo might be from “whoever”, NOT following the home:… naming convention

If you take a look within OBS and specifically ‘filesystems’, you’ll find that the openSUSE maintainer of ‘davfs2’ is Pascal Bleser. You’ll need to contact him to determine if, he’s an openSUSE volunteer or a SUSE employee.
<https://build.opensuse.org/>; <https://build.opensuse.org/project> (search for “filesystems”); <Welcome - openSUSE Build Service.

AFAIK, projects which are not prepended with “home:” are openSUSE projects managed by the people responsible for the openSUSE distribution.

Yes, “Zypper” is powerful but, “rpm” is still needed for some of the more difficult dependency issues: “rpm --query --whatrequires bluefish”

Taking a quick look at the output of “zypper repos --sort-by-priority --details”, I would hazard a guess that, Zypper sorts repositories with the same priority alphabetically by the “Alias” text string. Therefore, to force Zypper to order the selection of repositories, one has to use the “Priority” functionality.

This URL <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory> and this section: “How to become a maintainer of a package in Factory”.

knurpht · February 23, 2018, 8:36pm

My advice: do not mess with priorities, rather use ‘zypper dup --from repo_name_here’ . That would perform a vendor change for the package in that repo, and avoid conflicts ( unless the packages in that repo conflict.