Re: Using backported debhelper considered tricky
Thorsten Glaser:
> Hi *,
>
> I’d like to break a point in favour of *not* using backported
> debhelper when the backport otherwise builds fine in stable
> (or oldstable for that matter).
>
>
> ① The recent update of debhelper Breaks qt5-qmake in the version
> in stable and there is no backported Qt fulfilling its dependency.
>
> This leads to an irritating error message in pbuilder-satisfy‐
> depends-aptitude (depends on debhelper (>= 11~) but cannot be
> installed), but is otherwise circumventable.
>
>
> ② Worse, though, it Breaks cmake in the version in stable, but
> there *is* a backported cmake available.
>
> This can introduce undesired dependencies on other backports.
>
>
> I’ve uploaded my package with a debhelper revert now (had to
> do this for jessie-backports-sloppy anyway, so no biggie, I
> was only using debhelper 11 in sid because lintian started
> complaining when one was not using the latest and greatest…).
>
>
> This is not to say that this should be a general policy, just
> describe my perceived issues with it and serve as food for
> thought before blindly using the latest and greatest. (Yes,
> backreference intended. No slight against the lintian main‐
> tainers intended, though.)
>
> bye,
> //mirabilos
>
Hi,
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.
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).
But given the relevant version of cmake is in -backports, I do not
understand how that is worse than qt5-qmake?
Thanks,
~Niels
[1] 2f076eb7897d6fbea6f10ebd91354f637e706bd9
Reply to: