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
Attachment:
pgprc1_IsyvjX.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
