Re: RFC: Making gir1.2-* bundles Provide all their canonical names

Michael Biebl <[email protected]> Sat, 4 Nov 2017 16:09:28 +0100

Newsgroups	gmane.linux.debian.devel.gtk-gnome
Message-ID	<[email protected]>

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?

signature.asc (application/pgp-signature, 833 B)