Re: RFC: Making gir1.2-* bundles Provide all their canonical names
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
Reply to: