1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.GTK.GN

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

    From Simon McVittie@21:1/5 to All on Thu Nov 2 16:40:02 2017
    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)
  • From Michael Biebl@21:1/5 to All on Sat Nov 4 16:10:02 2017
    To: [email protected] (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-
  • From Simon McVittie@21:1/5 to Michael Biebl on Sat Nov 4 16:30:01 2017
    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)
  • From Emilio Pozuelo Monfort@21:1/5 to Simon McVittie on Sat Nov 18 13:30:02 2017
    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)