On 04/11/17 16:19, Simon McVittie wrote: > On Sat, 04 Nov 2017 at 16:09:28 +0100, Michael Biebl wrote: >> Am 02.11.2017 um 16:33 schrieb Simon McVittie: >>> I'm tempted to modify the Lintian check to do this: >>> >>> * If gir1.2-foo-1.0 contains Bar-2.0.typelib and has >>> Provides: gir1.2-bar-2.0, then don't emit >>> typelib-package-name-does-not-match for it >>> >>> * If libfoo-dev contains Bar-2.0.gir and Depends on gir1.2-foo-1.0, >>> and gir1.2-foo-1.0 is being processed in the same batch of packages, >>> and gir1.2-foo-1.0 has Provides: gir1.2-bar-2.0, then don't emit >>> gir-missing-typelib-dependency for it >> >> What I'm missing is, what we should recommend rdeps to do: >> If a package say requires TrackerControl-2.0, should it depend on >> gir1.2-tracker-2.0 or the virtual gir1.2-trackercontrol-2.0? > > Either seems fine, particularly now that we have versioned Provides. > Using the more precise dependency (gir1.2-trackercontrol-2.0) makes > the dependency graph a little more complex for apt to disentangle, but > means we would be free to split gir1.2-tracker-2.0 with a minimum of > Breaks in future. > >> If the latter, how would we enforce, that users depend on the "right" >> package name? > > We don't currently have a way to enforce correct/sufficient dependencies > for users of g-i via Lintian or similar (we can't easily tell which g-i > modules are used by Python or JavaScript code, and whether they're > conditional or mandatory) so I don't think this is a regression.
We could update dh_girepository to generate dependencies on the provided packages when that makes sense. That won't help with applications as you say, but it will help with gir package dependencies. Cheers, Emilio