On martes, 8 de agosto de 2023 04:50:04 -03 Helmut Grohne wrote: > 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? I can definitely agree with this as long as it's an opt-in. In fact it could be useful to run it from time to time or even have a way to say "run but ignore this or that case". Of course this might be trickier: it is totally possible for a header to declare conditional includes depending on the platform.
Attachment:
signature.asc
Description: This is a digitally signed message part.