Re: autodep8 test for C/C++ header
Hi Sune,
On Tue, Aug 08, 2023 at 06:46:38AM -0000, Sune Vuorela wrote:
> I don't think this is a important problem that some headers might have
> special conditions for use. I'd rather have our developers spend time
> fixing other issues than satisfying this script.
A while ago, I've performed a similar analysis for Python and given my
experience there, I disagree with you here. As far as I understand both
you and Peter, you argue that such an autodep integration would fail for
some package for various (valid) reasons. What Benjamin seems to propose
is adding support for an automated check that is opt-in (not opt-out).
As a developer, you have to explicitly enable it in order to use it.
Given the numbers presented by Benjamin and the examples presented by
both Peter and you, I expect that Benjamin's script would just work for
at least half of the packages. And for those where it just works, I see
it as a useful safety measure.
> Is it a problem that Qt -dev packages also ships windows, mac or android
> specific addons headers? I don't think so. Rather the opposite. When
> doing cross platform work, it is nice that grepping across the includes,
> I also see some of the platformspecific functions in separate files.
>
> Is it a problem that a header file is also shipped that provides
> integration with other-big-thing but 99% of developres/downstream users
> don't care about and no Depends is in place? I don't think that's a
> problem. I'd rather have the header available for the 1% than having to
> create an extra -dev package just for that.
>
> Debian development resources is a finite resource, so let's not waste
> it.
This goes both ways. The team at Canonical is currently dealing with
lots of failures that are tangential to time64. Let's not waste their
time either. I'm experiencing a similar issue with my work on
/usr-merge. In order to complete that transition in a safe way, I need
file conflicts to be precisely declared, but people frequently introduce
new ones and some even argue about their severity. That's also "wasting"
my time.
So from my point of view, we need to strike a balance here. Benjamin is
offering an opt-in tool to reduce his waste time. Having half of the
packages opt into it, would already reduce QA work significantly, so
that sounds like a very good measure to me.
Can we agree on moving forward with this while not forcing it onto each
and every package?
Helmut
Reply to: