[Debian-olpc-devel] 0.84/0.86 dependencies on Lenny (was: Re: lenny (debian.jones.dk): broken metacity)
dr at jones.dk
Fri Nov 6 17:51:13 UTC 2009
On Fri, Nov 06, 2009 at 06:19:19PM +0100, Sascha Silbe wrote:
>On Fri, Nov 06, 2009 at 05:39:41PM +0100, Jonas Smedegaard wrote:
>>>IIRC that was the reason I stopped trying to run sugar-jhbuild in
>>well, in principle sugar-jhbuild, jhconvert or whatever other
>>packaging method should work too, as long as the tedious work of
>>digging out all the dependencies is done properly.
>According to a commit log entry the problem was that we needed a more
>recent version of gtk+ (i.e. one which included gio) and couldn't get
>it to build and install inside sugar-jhbuild (don't remember the
I am not an expert here, but I believe GIO is not in GTK+ but glib.
GTK+ depends tightly on glib, which may explain how updating that solves
the GIO dependency.
>Since you're updating the distro package instead, it might actually
>work in the end (but with the risk of breaking non-Sugar packages
>that use gtk+).
Using one GTK+ for the main system and another for Sugar requires more
memory, and has a higher risk of security issues going unnoticed.
Especially when compiled "by hand" from tarball sources (compared to
pulling packaged libraries which - at least in theory - have more users
and more robust security tracking).
But yes, upgrading GTK+ has a risk of ruining everything else on that
The more unofficial packages you pull into a system, the higher the risk
I do my best to respect dependencies declared in packages that I
backport. This helpst but is no assurance against breakage: unusual
combination of library versions are obviously less tested by anyone
(e.g. run a bleeding edge Gnome library against an old version of
another Gnome library, instead of bumping them all together).
But really, upstream code (real code written in C) should detect and
refuse to compile against versions of libraries not working, and
packaging should ensure that compiled libraries cannot get out of sync
So if I succeed of backporting some libraries (without cheating by
hacking the dependency declarations) and the resulting mixture breaks,
then it is an error in the packaging and possibly upstream as well.
So please do crash-test, and tell all problems in the odd mixture that I
provide. It may be helpful also for more classical mixtures to do this
>>Currently I do that manually: read all(!) code looking for imports
>>and execution of non-python code.
>Though there's no complete list of dependencies for each single
>package, you can
>a) check the sugar-jhbuild dependency lists 
>b) check the Release Notes for new/updated dependencies 
I try to do both already - but trsut the actual code more than misc.
notes scattered all over. :-/
I was more dreaming about a script that scans a folder full of Python
code, spitting out a list of all external modules that it depends on.
>>If anyone knows about a tool to extract all "import" statements in
>>Python code, I would much appreciate it!
>find -name "*.py" |xargs grep -h import |sort -u
Yeah - better than nothing. Some time ago I wrote a loooong perl
one-liner doing above + some kinds of calling shell commands, but then
by seession dies and with it the one-liner which off course wasn't
written down anywhere yet and didn't even gt saved to the bash history
>The "magic" stuff should usually be safe to ignore as it's for
>loading plugins, not external dependencies (AFAICT at least).
What "magic"? I lost you there.
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the Debian-olpc-devel