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