Re: Using backported debhelper considered tricky

[Niels Thykier <niels@thykier.net>]

Thorsten Glaser:
> Hi Niels,
> 
>> The Breaks on qt5-qmake in debhelper is allegedly to assist with
>> cross-building[1].  However, given most cross-building efforts are done
>> in sid and the relevant version of qt5-qmake has long been in
>> testing+sid, I suspect we can drop that Breaks again.
> 
> okay.
> 
>> As for cmake, that breaks is to ensure you get the same result in sid
>> vs. stretch-backports in compat 11 (see debhelper changelog for 11.1).
> 
> I fear that that changelog entry and #886127 do not contain
> enough information for me to comprehend what’s going on there.
> 

  - The cmake buildsystem now passes -DCMAKE_INSTALL_RUNSTATEDIR=/run to
    cmake(1).

But cmake ignores the option in stable

>> But given the relevant version of cmake is in -backports, I do not
>> understand how that is worse than qt5-qmake?
> 
> It’s “probably” not a problem for cmake, but with other things
> debhelper can have a Conflicts or Breaks on, this may introduce
> undesired and otherwiese unnecessary dependencies on other back‐
> ported packages.
> 
> bye,
> //mirabilos
> 

An overview of the debhelper Breaks situation for stable-backports:
 * "dh-systemd (<< 1.38)" => replaced + provided by debhelper itself
 * "cmake (<< 3.9~)" => satisfiable in stretch-backports
 * "meson (<< 0.40.0~)" => satisfiable in stretch-backports
 * "qt5-qmake (<< 5.9.2+dfsg-8)" => discussed above/previously

So it seems to me that the only problem is qt5-qmake for
stable-backports?  From my PoV, you are welcome to do a new ~bpo upload
of debhelper/11.3.2 backport that removes that breaks as it is certainly
not applicable for ~bpo.

Thanks,
~Niels