Created attachment 191450 [details]
Definitions of the generator

This should get installed in /usr/lib/rpm/fileattrs/

Created attachment 191451 [details]
Script to analyze the files

All this work was done by Dominique Leuenberger, btw :-)

drive-by comment: we need this for gsettings schemas too. Very few packages in Fedora depend on gsettings-desktop-schemas, which is kinda bad given the "abort on missing schema" thing.

Sounds good to me, in principle.

For Fedora, we still need to get this accepted by the packaging committee, but that shouldn't preclude its upstream inclusion.

Sent mail to the packaging committee now:

http://lists.fedoraproject.org/pipermail/packaging/2011-July/007832.html

I don't understand why the indirection; while it's true that a JavaScript or Python script depends on the typelib, it *also* depends on the native library.

So why not just have this dependency scanner emit that?  For example, a Requires: libglib-2.0.so.0()(64bit) or whatever.

Note that even if going with the indirection approach, this script really needs to handle versions, otherwise it's going to fail in the most important cases (like gtk2 versus gtk3).  In fact, I'd say it should *only* support the versioned case (and we should really deprecate unversioned imports in both JS and Python).

(In reply to comment #7)
> I don't understand why the indirection; while it's true that a JavaScript or
> Python script depends on the typelib, it *also* depends on the native library.
> 
> So why not just have this dependency scanner emit that?  For example, a
> Requires: libglib-2.0.so.0()(64bit) or whatever.

Because there might be reasons to not have the typelib in the same package as the library (on Debian, for instance, it's a different package). What we know for sure is that the typelib must depend, packaging-wise, on the library. We don't know more than that.

> Note that even if going with the indirection approach, this script really needs
> to handle versions, otherwise it's going to fail in the most important cases
> (like gtk2 versus gtk3).

There's already preliminary support for that (although not for all forms), but yes, we probably want to complete (or rewrite) that.

> In fact, I'd say it should *only* support the
> versioned case (and we should really deprecate unversioned imports in both JS
> and Python).

I think that'd be wrong, unless unversioned imports in js/python get unsupported. It's really too easy to break packaging because of this.

Fedora Packaging Committee discussed this briefly and decided that we don't have enough information to decide on most things.  Asked some questions here that weren't answered:
  http://lists.fedoraproject.org/pipermail/packaging/2011-July/007833.html

One thing that we did agree on at our meeting today, though, was that typelib() is a bit generic.  If you could namespace it (something like goi-typelib() was proposed at the meeting).

These Requires and Provides are a bit "interesting".  It would be nice if they could be coordinated across distros but putting them into project packages upstream runs the risk of not getting coordination across projects.  namespacing is one way to help with this.  Another might be to coordinate this with rpm.org (even if they don't want to provide the dep generators in rpm itself, maybe we could document on their wiki what dep namespaces are being used.)

Regarding the dep-gen script implementation, the message I linked has some comments about shortcomings in the python extraction.  Relevant to the talk about versioning is that at least the comments about extracting versioned deps for python is wrong.

A quick update on my thoughts on this; basically 0) is a blocker for me merging this, the rest are somewhat optional but would be nice.

0) Must support versioned syntax - otherwise we get incorrect results for people who try to Do The Right Thing.

1) Shell script is really not an ideal language for, well just about anything, but parsing source code is a particular low point.  I guess this goes along with Toshio's comments about Python syntax handling.

2) No objections to goi-typelib() over typelib().

3) Does it really work to use /usr/lib/rpm/fileattrs for all current RPM consumers or do we need configure logic here?

4) The implementation of function find_provides is wrong - we should only add Provides for typelibs in $libdir/girepository-1.0.  Otherwise we'll pick up private typelibs (like /usr/lib64/gnome-shell/Shell-0.1.typelib which no component outside of gnome-shell should be using)

(In reply to comment #10)
> 0) Must support versioned syntax - otherwise we get incorrect results for
> people who try to Do The Right Thing.

This is already the case (unless I misunderstand what you mean):

$ rpm -q --requires gnome-shell | grep typelib | grep Meta
typelib(Meta)  
typelib(Meta) = 3.0

(interesting that we have both -- that's because the shell is using versioned and non-versioned imports)

> 3) Does it really work to use /usr/lib/rpm/fileattrs for all current RPM
> consumers or do we need configure logic here?

Good question. Dominique, do you know? I'd think it's standard (we can always add the configure logic later if needed).

> 4) The implementation of function find_provides is wrong - we should only add
> Provides for typelibs in $libdir/girepository-1.0.  Otherwise we'll pick up
> private typelibs (like /usr/lib64/gnome-shell/Shell-0.1.typelib which no
> component outside of gnome-shell should be using)

typelib(Meta) is exactly one example showing why we need this: mutter installs its typelib in /usr/lib/mutter/Meta-3.0.typelib. I agree it's not an amazing thing, though :/

For reference, the latest files are available at https://build.opensuse.org/package/files?package=gobject-introspection&project=GNOME%3AFactory (it's likely that we had some changes since last July).

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]

Created attachment 326974 [details] [review]
g-ir-dep-scanner: Scan dependencies of a typelib and give information.

This allows distributions to create automatic dependency tracking coming
from .typelib files.

The dependencies identified at this time are:
typelib - based dependencies
shared library - dependencies

Reference: https://bugzilla.gnome.org/show_bug.cgi?id=654156
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>

Created attachment 326975 [details] [review]
g-ir-dep-scanner: Scan dependencies of a typelib and give information

This allows distributions to create automatic dependency tracking coming
from .typelib files.

The dependencies identified at this time are:
typelib - based dependencies
shared library - dependencies

Reference: https://bugzilla.gnome.org/show_bug.cgi?id=654156
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>

(In reply to Igor Gnatenko from comment #15)
> Created attachment 326975 [details] [review] [review]
> g-ir-dep-scanner: Scan dependencies of a typelib and give information
>

Note that this bug is not about the scanner itself: the introduction of the same is handled in bug 665672  - Don't mix up things or patches go lost in one or the other.

Review of attachment 326975 [details] [review]:

Patch does not belong to this bug - let's not duplicate the patches in multiple bugs. This only leads to nobody knowing which patch should be used in the end.

(In reply to Dominique Leuenberger from comment #17)
> Review of attachment 326975 [details] [review] [review]:
> 
> Patch does not belong to this bug - let's not duplicate the patches in
> multiple bugs. This only leads to nobody knowing which patch should be used
> in the end.

ah, I didn't know about that bug.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/53.