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. smcv