Quoting Marc 'HE' Brockschmidt <he@debian.org>:
"Roberto C. Sanchez" <roberto@familiasanchez.net> writes:I just had a grave bug filed against my releaseforge package. I have traced the fault to an issue with the version of pyqt-tools. If the package is compiled with the version of pyqt-tools in sarge (3.13), it needs to run against python-qt3 version 3.13. However, if it is compiled against pyqt-tools from Sid (3.14), it needs the corresponding python-qt3. What is the correct way to specify the depends and build depends?If it compiles with *all* versions of python-qt3, you should use an unversioned build-dependency. In that case you only need to get the binary dependency right, which is pretty easy if you use something like "Depends: python-qt3 (= ${python-qt3:Version})". You then only need to get the version number of the python lib you used to build the package (either with some package-specific tool or dpkg -l) and add a "python-qt3:Version=1.2.3" to debian/substvars.
OK. How do I get that line to appear in debian/substvars? I know that if
I put ${python:Depends} in the Depends line, then I "magically" get the
right dependency. But, I don't understand how it works.
What I ended up deciding was to simply build-depend pyqt-tools (>= 3.14.1).
This is because .py scripts built with 3.14.1 and newer are compatible with
older versions of python-qt3. However, allowing builds with the older
version ensures that when python-qt3 3.14.1 transitions from Sid to Etch,
anyone that happened to have their package built with pyqt-tools 3.13 will
see it break. Since my package will not make it into Sarge, I don't think
it is a problem to Build-Depend on the newer version. Besides, the Python
maintainers have enough to deal with figuring out how to properly conflict
with all the packages that happened to be built with pyqt-tools <= 3.13
and didn't specify a versioned Build-Depends.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr