[Fedora-packaging] Automatic dependency generation: gobject-introspection

[Toshio Kuratomi]

On Fri, Jul 08, 2011 at 03:52:08PM -0400, Matthias Clasen wrote:
> The OpenSuSE folks have been working on automating dependency
> information for use of libraries via gobject-introspection.
> Their generators currently cover python and javascript, you can see them
> here:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=654156
> 
> I'm really happy to see this being pushed upstream, and it will probably
> land in rawhide with the next GLib release (in ~ 2 weeks) unless the
> packaging committee has objections.
> 
> If we need to amend any packaging docs for this, let me know.
> 
Need a bit more information about what the whole thing does to figure out if
we or it need to make any changes.

What's the definition of a typelib here?

Is the term "typelib" used in other places/frameworks/systems/etc that would
like to use rpmdeps?  If there are, would those instances be compatible with
this or, for instance, would they be providing their own foo::typelib(Gtk)
since their idea is different and incompatible?

Depending on the above -- we might want to rename typelib to be a bit more
specific (gi_typelib()?  gi::typelib()?  typelib::gi()?)  but I really don't
know the answers about how generic the term typelib is and how specific the
gobject implementation is.

It talks about only working for python and javascript.  Reading the code I'm
pretty sure that this applies only to Requires, not to Provides which is
good.

I'm not clear if any language can validly provide a typelib "libray"
but I'm not sure if that would be a problem either (the only problem I could
see is if this causes compatibility issues between typelibs somehow -- if
that's not the case, then there's no problem here.)

Will this collide with the proposals that have occurred from time to time
for pulling out python deps?  (Partially answer this for myself: The only
thing I can think of is it'll result in duplicate requirements which aren't
a problem for correctness.  I know we've talked about duplicate requirements
for, for instance, glibc (actually 5x requirement) causing metadata size to
increase which is a space/download issue for depsolvers.  Geppetto can weigh
in on this aspect.)

The implementation has a few caveats for the python implementation that
should probably be recorded in the comments or fixed:

Does not catch multiline imports and may trip over them:
  from gi.repository import foo \
       bar
  from gi.repository import (foo,
       bar)

The latter is also a caveat in single line imports:
  from gi.repository import (foo, bar)

Does not catch the simple import statement:
  import gi.repository.foo

The example:
#   . from gi.repository import foo-1.0 [versioned requirement]
is invalid python (the minus sign makes it invlaid).  It should be removed
from the comments.  I don't know if gobject introspection has a valid method
of specifying a version here that should replace this example.

I'm cautiously optimistic that this wouldn't cause any changes to the
packaging guidelines.  The potential of "typelib" being too generic should
be addressed, hopefully upstream if it is in fact a problem, but we could
patch it localy if we decided that it was necessary (the drawback there is
that people couldn't install rpms using typelibs across distros... something
that's already somewhat iffy.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110708/923a3248/attachment.bin