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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
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

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
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 | Threaded
Open this post in threaded view
|

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

Emilio Pozuelo Monfort-4
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