Hi Simon 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 > > and include that convention in the g-i mini-policy. > [..] > which would silence the warnings. What do people think of that plan? E.g. in tracker I'm in a similar situation where I decided to bundle all .typelib files in a single gir1.2-tracker-2.0 shipping /usr/lib/*/girepository-1.0/Tracker-2.0.typelib /usr/lib/*/girepository-1.0/TrackerControl-2.0.typelib /usr/lib/*/girepository-1.0/TrackerMiner-2.0.typelib I can be reasonably sure, that the version of those typelibs is upgraded in lock-step, so I didn't bother with splitting them up. Atm, I do indeed ship a lintian override and with your proposal, I would be able to drop that. We should emphasize that this bundling of typelib files should only be done when those are from the same source package and it's pretty much certain that they are versioned the same. 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? If the latter, how would we enforce, that users depend on the "right" package name? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature