Some packages bundle several related GIR modules, for example
gir1.2-glib-2.0 and gir1.2-gtk-*. At the moment Lintian can't understand
this structure, and issues warnings.

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.

Then (for example) gir1.2-gtk-3.0 would gain

Provides: gir1.2-gdk-3.0 (= ${binary:Version}),
gir1.2-gdkx11-3.0 (= ${binary:Version})

which would silence the warnings. What do people think of that plan?

(This would also mean that if maintainers look at their GIR dependencies without knowing which packages have special cases, and add a dependency
like Depends: gir1.2-gdk-3.0 (>= 3.24), the right thing would happen.)

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: smcv@debian.org (Simon McVittie)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rjqOoJXOoENHtcnpPpkls9MF4hdie7Oe0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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?


--rjqOoJXOoENHtcnpPpkls9MF4hdie7Oe0--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAln92CsACgkQauHfDWCP ItwwCQ/+OJyt7L3W8E9EmeEYAINdnPkJ4ybcBizECc026quUQlAq8FTyJUqDS6Mv zbRGMmGnCsiBGtNWKRIFFZKAiYE2LOrWNUTtfxQieCxBwUBemRh4oz0e+oHAedKP X6MSwLvrNuGB1TS2Lr4+xJvsG/qTd23oHMRkgkSfsljLMPQA0uXeD5ckTQFGQZO7 ueILaoLnyPXhHCY6YNznUdG6CaZ52eBQK12yCTZ/PF0+WE5drcjXYNUpjP+sNE5e NyHx3OgTOwvaiKs8Qh19+TqU+ptG1cH7+WulalzXLjVlmTZv/iZdTn7ZlnxYDf4W fCi/zyaGbkvM9CODltQVHKFylIQOA6wVcx2qFBS2Q29bZdtBSxe6XLFI9zM/cano TbQ9HgYdKyrUOcRrYh8cdQEXzLb1YaKLXeu2gYCcGfLcX3P1Extgsy8twyNH8sQz A4u65K7l+HxlUJzs/jgt81zl1k5vThYgkjR70RyOvWh6eH4+mRbbIXc91PI6oaiz VNRwslOSZM4U2/drFR0GGEmuArqkYles35R1nVJtZnXYPes5S22lPGBpkRa71zEE ppPadyAF+BljKMlGJx8HozFtpn98SVXPgmu/K9rTiC9D5r5iSaoFCx90xWcVbsC/ w33SISH1xeYjs162/KEmETBW0nM4l/ASlTUIXZJVcmk8iaqm/+E=
=80/r
-----END PGP SIGNATURE-----

--- SoupGate-

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)