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