[Debian-olpc-devel] 0.84/0.86 dependencies on Lenny (was: Re: lenny (debian.jones.dk): broken metacity)

[Jonas Smedegaard]

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  
>>>lenny... :-/
>>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 
>exact problem).

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 
machine.

The more unofficial packages you pull into a system, the higher the risk 
of breakage.

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 
through upgrading.

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 
shake-down.



>>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 [1]
>b) check the Release Notes for new/updated dependencies [2]

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

-- 
* 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20091106/da2a9447/attachment.pgp>