Re: Using backported debhelper considered tricky
Thorsten Glaser:
> On Thu, 7 Jun 2018, Niels Thykier wrote:
>
>> An overview of the debhelper Breaks situation for stable-backports:
>
> Thanks, that certainly is useful.
>
You are welcome. :)
> It pertains to the Breaks of debhelper as-it-is-now.
> This list may change over the lifetime of backports,
> though.
>
While that is true, but in general it is in my interest to make
debhelper as stable-backports compatible as possible. The qt5-qmake
case could have been handled better in my end, but all the others have
been carefully chosen based on availability in stable-backports.
> I was not advocating against using backported debhelper
> in general, just indicating one should not do so mindlessly.
> (I’m impressed with your response, though.)
>
As implied above, I have personal interests in making the backported
debhelper "just work(tm)" to the extend possible. This attempts to cover:
1) that you are trivially able to use/Build-Depend on debhelper in
stable-backports, and
2) that debhelper behaves the same as in sid.
In the case of cmake, I prioritized 1) higher than 2) until cmake was
available in stable-backports (see [1]). Fortunately, we have cmake now
and I can now provide you with 1) + 2) for cmake related packages.
>> 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.
>
> OK, thanks, I won’t do so though as I don’t need it (now);
> someone else might, or perhaps with the next upload.
>
> bye,
> //mirabilos
>
I have removed the qt5-qmake breaks in the master branch of debhelper.
But my offer still stands if anyone wants to do a "quick fix" to bpo.
Please push your changes to
https://salsa.debian.org/debian/debhelper/blob/stretch-backports/ if you do.
Thanks,
~Niels
[1]
https://salsa.debian.org/debian/debhelper/commit/c1e2bbd0858b29ff1c90427501480c27e885d5b6
Reply to: