Project

General

Profile

Actions

Bug #188

closed

Qt version numbers

Added by Guilhem Saurel over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-

Description

Hi,

While trying to install robotpkg-qt4-gepetto-viewer-corba with apt on 16.04, I got this error:

Les paquets suivants contiennent des dépendances non satisfaites :
robotpkg-qt4-gepetto-viewer-corba : Dépend: libqt4-dev (< 5) mais 4:4.8.7+dfsg-5ubuntu2 devra être installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

So I think that, on ubuntu at least, the version check of Qt should be something like "< 5:0" instead of "< 5":

dpkg --compare-versions "4:4.8.7+dfsg-5ubuntu2" lt 5 # KO
dpkg --compare-versions "4:4.8.7+dfsg-5ubuntu2" lt "5:0" # OK

Actions #1

Updated by Guilhem Saurel over 5 years ago

This will also affect Debian, as the source of this seems to be:

Add epoch 4 to avoid headache for Phonon handling.

in https://metadata.ftp-master.debian.org/changelogs//main/q/qt4-x11/qt4-x11_4.8.7+dfsg-17_changelog

Actions #2

Updated by Anthony Mallet over 5 years ago

On Thursday 6 Dec 2018, at 16:54, Guilhem Saurel wrote:

This will also affect Debian, as the source of this seems to be:

Add epoch 4 to avoid headache for Phonon handling.

... and create headache elsewhere instead ...

Here is how it works:

  • The version requirement "<5" comes from robotpkg (sysdep/qt.mk), as
    it wants to not match qt5.
  • The conversion from a robotpkg dependency to a debian dependency is
    done thanks to the SYSTEM_SEARCH.qt4-libs variable. For each file,
    the resolved prefix is added and something like
    `dpkg-query -S /prefix/file` is used to retrieve the package name (e.g.
    /usr/lib/x86_64-linux-gnu/pkgconfig/QtCore.pc -> libqt4-dev)
  • The constraints (e.g. >=4<5) are then added to each debian package
    name.

Right now, I see no way to invent a meaningful "epoch" number in this
process.

The idea of "epoch" is debian-specific, it does not make sense for
robotpkg (hence not possible ATM to inject it anywhere).

Actions #3

Updated by Anthony Mallet over 5 years ago

The only trick I can think of would be:

  • Given a debian package dependency X found with dpkg-query -S, get the
    epoch of the installed version with
    `dpkg-query -Wf '${Version}' X | sed -ne '/:.*/s//:/p'`
    And stick that in front of the robotpkg version requirements

But this is not so good, as if a debian package grows like this

  • X-1.0
  • X-1:1.1

Then a robotpkg requirement X>=1.0 would be transformed into X>=1:1.0
(assuming X-1:1.1 is installed), thus failing to accept X-1.0.

Actions #4

Updated by Guilhem Saurel about 5 years ago

but if the debian package is updated with a new epoch, this is not a big issue to fail accepting the older package without epoch, is it ?

Actions #5

Updated by Anthony Mallet about 5 years ago

On Friday 8 Feb 2019, at 15:16, Guilhem Saurel wrote:

but if the debian package is updated with a new epoch, this is not a
big issue to fail accepting the older package without epoch, is it ?

I guess it is not so bad, yes. Especially since it should not concern
many dependencies. Not sure why Qt got this bump ...

Actions #6

Updated by Guilhem Saurel about 5 years ago

  • Status changed from New to Closed

Fixed by 9aca14ca. Thanks !

Actions

Also available in: Atom PDF