robotpkg

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

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).

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.

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 ?

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 ...