Installer does not find libvorbis on Fedora

Bug #598115 reported by Matthias Klumpp on 2010-06-24
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Listaller
High
Matthias Klumpp
PackageKit
Invalid
Wishlist

Bug Description

While installing Osmos Demo, the installer says it can't find any package providing libvorbis.so. But the package exists. Installing the same IPK package on Debian works fine.

Listaller 0.4-Git, Fedora Core 13, GNOME, PackageKit 0.6.5

Matthias Klumpp (ximion) wrote :

Delays the 0.4b release...

Changed in listaller:
assignee: nobody → Matthias Klumpp (ximion)
importance: Undecided → High
milestone: none → 0.4b
status: New → In Progress
tags: added: installer
Matthias Klumpp (ximion) wrote :

Regex was incomplete: "*" was missing at the end of the dynamic dependency. Committed patch for liCreator and libuild to add "*" automatically. Rebuilt Osmos Demo package.

Changed in listaller:
status: In Progress → Fix Released
Matthias Klumpp (ximion) on 2010-06-25
Changed in listaller:
importance: High → Medium
Matthias Klumpp (ximion) wrote :

Definitely not fixed, this bug appears again some times. Need to investigate.

Changed in listaller:
status: Fix Released → In Progress
Matthias Klumpp (ximion) wrote :

This function is missing in the yum-Backend of PackageKit, I'm not quite sure if yum is able to search for incomplete file names...

Changed in listaller:
importance: Medium → High

Hello!
It would be very important for me to be able to use wildcards in PackageKit's search terms. For example on a Debian-based machine
 $ pkcon search file '/usr/lib/libogg.so.'
finds the right package containing a version of libogg.
The same on Fedora does not throw any result, cause the Yum backend needs a more specific search command than Apt requires:
 $ yum provides '/usr/lib/libogg.so.'
does not find anything, but
 $ yum provides '/usr/lib/libogg.so.*'
using the asterisk as wildcard, does find a package. If I try to submit a string containing an asterisk using pk_client_search_files_async(), PackageKit does not process the command and throws a warning about "Invalid search containing '*'".
This causes applications using PackageKit to find a package on some distributions and on some others not although it is avaliable. (Depending on the backend PKit uses)
It would be great if wildcards could be submitted to the backend if it supports them. (Otherwise a fallback would be nice) I think most of the packaging tools support wildcards, so why not make PackageKit able to use them? (I think not only me but also a lot of other people who use pkcon in scripts would be happy about this option)

Matthias Klumpp (ximion) wrote :

PackageKit does not support regular expressions as used by Listaller, so "libogg.so.*" cannot be found. On Debian-Based machines, this is converted to "libogg.so." which makes Listaller able to find the right file. On Fedora's Yum this does not work.
A patch for PackageKit is needed, which makes using regular expressions - or at least using the asterisk - possible.
Yum is able to process commands like
 $ yum provides '/usr/lib/libogg.so.*'
but PackageKit is not:
 $ pkcon search file '/usr/lib/libogg.so.*'
 => failed: Invalid search containing '*'

Matthias Klumpp (ximion) wrote :

To Fedora users who want to try the Osmos demo package anyway: Try to use the "--force-depends" parameter:
 $ listallmgr-qt /path/to/osmos-package.ipk --force-depends
 (or use listallmgr-gtk)
This will make Listaller skip the dependency check. You might have to install some dependencies by hand afterwards to make it work.

Changed in listaller:
importance: High → Medium
status: In Progress → Confirmed
Matthias Klumpp (ximion) on 2010-07-11
Changed in listaller:
importance: Medium → High
Matthias Klumpp (ximion) on 2010-07-11
Changed in listaller:
milestone: 0.4.00b → none
Matthias Klumpp (ximion) wrote :

The upcoming Listaller 0.5 series will have features which avoid using wildcards with PackageKit. Unfortunately the new methods completely break the API/ABI, so it is impossible to fix this bug in 0.4b series.

Changed in listaller:
milestone: none → 0.5-alpha1
status: Confirmed → In Progress
Changed in packagekit:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Changed in packagekit:
importance: Wishlist → Unknown
Matthias Klumpp (ximion) wrote :

Listaller will soon receive some updates to work around this limitation.

Changed in packagekit:
importance: Unknown → Wishlist
Matthias Klumpp (ximion) wrote :

This one will be fixed soon with Listaller support modules in PackageKit and the new advanced dependency solver, based on cool stuff from AppStream, ZeroInstall and - of course - Listaller ;-)

Matthias Klumpp (ximion) wrote :

Marking this as fixed, since the rewrite of Listaller (series 0.5.x) will have completely different dependency-resolve functions, which should solve this issue.

Changed in listaller:
status: In Progress → Fix Released

We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues

Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.

Changed in packagekit:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.