Main Development Beginning, Stage 1 Information Options

[_Psycho]

It would not be possible to do a script
that read the ipk, extract the file
do a ldd on the executable, and see the depencies
and automaticaly list the librairies in the project ?

I know i ask for a lots =P

Nice job btw, i saw the screenshots. Its going to be great to see the front page result with the new items etc kinda like freshmeat

[lardman]

...and I'm sure someone who's better at shell scripts than I am could come up with something which does a 'ls /lib/*.so.?.?' and 'ls /usr/lib*.so.?.?' and collates the info for the standard-libs-in-such-and-such-a-ROM database for the above to be compared against.

(dz - beginning to regret taking this on? )


Si

[dz]

Heh, no i don't regret it. This is a fun project

As far as making a script that reads the file, the only problem I see with that is server load.

I'm not exactly positive of the structure of IPK's, but even if I were to extract it, how would I know which file to check? Is there some kind of way to find out?

[lardman]

I'm not exactly positive of the structure of IPK's, but even if I were to extract it, how would I know which file to check? Is there some kind of way to find out?

If you're thinking of the control file, it's always the only file in the control.tar.gz file which is inside the ipk.

If you're wondering which file to look at and run ldd on, that's a bit more compilcated. A couple of ideas: extract the data.tar.gz component of the ipk, then look at all files in any bin directory (because they could be /bin, /opt/QtPalmtop/bin, /usr/bin etc.), might also be worth looking inside lib directories too if there are no bin directories; check the file permissions.

As far as making a script that reads the file, the only problem I see with that is server load.

Assuming you create a db rather than reading the file each time the data is requested it shouldn't be to bad (I reckon); unless the ipk submission rate goes up by a very large margin ;-)


Si

[lardman]

Addendum:

libc etc. are of the format lib*-?.?.?.so, so this would have to be added and searched for too.

ldd only returns the major versions of the libs which the binary is linked against. This is not supposed to be a problem (e.g. minor version changes aren't supposed to break things - at least that's what I understood), but can be sometimes. Libc version cannot be ascertained from ldd (unless the random numbers after the lib name actually mean something to somebody?).


Si

[dhns]

Yep, when a ROM is released get the authors to state their version of GCC and libc (which are the two main ROM dependant things I think).

This mainly recommends three (or four) different categories of software:
1. applications (.ipk) - ask for Model, ROM
2. ROMs - ask for Model, CPU type, gcc, libc, Memory, anything else
3. libraries
4. others

Having that it would even allow the maintainer of a ROM to add all the information by themselves.

Just another idea.

-- hns

[_Psycho]

As far as making a script that reads the file, the only problem I see with that is server load.

The server would only do it once. The way i saw it, its when someone upload an .ipk, the server offer him a list of libraries that his binary contain kinda like

Extract the .ipk
run ldd on the "binary" it to see the libs (might be tricky to fidn the binary
and return the result on the web page. So the author can edit them.

Not sure if its really required anyway, not like the author dont include the libs, or tell the dependancy needed "The project require libsdl and libmad".
etc...

[dz]

Ok, how about this. How about we formulate a list of libs, and when you are submitting a project, you are shown this list and are asked to select all the libs involved in your project.

That way, I dont have to mess with extracting IPK's and all that. I dont know how to tell which file i the executable or not, so I figure this way is the easiest.

I need a list of most libraries though. As well, if the user uses other libraries, they can request it added to the list.

That work?

[_Psycho]

Yes, thats actually sound a good way to do it

Maybe have version number and a link to download the library ipk if possible ?:
I know its a lots of more work. Not sure if its really gonna be usefull but something like that that i would see.

Requirement


the_frog_version_1.0.ipk
by Mr Froggy.
Work on: Cacko ROM, tckrom, Sharp ROM, OpenZaurus
Supported resolution(s): 640x480
Supported model(s): SL-C700, SL-C750, SL-C780, SL-6000
Processor(s): ARM5 (pxa250, pxa255)

----
This project include ALL libraries already needed to run this program.
----

This project require the following libraries (not included) to be installed on your ROM.
libsdl ­­>= 1.2.5
libpcap >= 1.0.3
libfreetype >= 2.4.5

The project include the following libraries:
libmad 0.41
libssl x.x.xx

----
Cacko ROM 1.22b include the following libraries:
libfreetype 2.6.5
libpcap 1.3.4

Sharp ROM doesn't have any required libraries

Tck ROM include the following libraries:
libfreetype 2.6.6

OpenZaurus ROM include all libraires needed.
-----

I dont know if its possible to have a list of libraries by rom but thats would be something similar.

[lardman]

I accept that you don't want the extra work, but for completeness...:

I dont know how to tell which file i the executable or not, so I figure this way is the easiest.

Look in all bin directories at all files which 'file' considers to be executables (or parse the ls -rtl data and see whether they are executable). May as well look in lib directories too if there are no bin directories ;-)

Nevertheless, some dependencies will be missed this way no matter what happens:- for example python scripts won't work without the runtime, but this wouldn't be picked up using the above to analyse the scripts (unless you want to get really complicated and also analyse the hash-bang in executable text files..... no sounds like a lot of work to me ;-))

I need a list of most libraries though. As well, if the user uses other libraries, they can request it added to the list.

Perhaps they should just add the info manually then rather than having a list (which will quickly grow rather large). Assuming the comments can be made for the entries, then the correct libs will soon be listed (by the author reading the comments and changing the main page, etc.).


Si

[lardman]

The project include the following libraries:
libmad 0.41
libssl x.x.xx

This, in itself, is somewhat problematic. I'd prefer it if people would just package up their program and list the dependencies rather than adding extra libs (which may overwrite the ones which I already have).

I dont know if its possible to have a list of libraries by rom but thats would be something similar.

This is relatively trivial, just run something like this on a clean install of each ROM (off the top of my head):

CODE

#!/bin/bash
# parse all libs on a Z
if [$1 = ]; then
   echo "no files given"
   exit 0
fi
for i in $( ls /lib/lib*.so.?.? ); do
   echo item: $i
done
for i in $( ls /lib/lib*-?.?.?.so ); do
   echo item: $i
done
for i in $( ls /usr/lib/lib*.so.?.? ); do
   echo item: $i
done
for i in $( ls /usr/lib/lib*-?.?.?.so ); do
   echo item: $i
done
# need to stick this info into a db
# check there are no duplicates first...?

This post has been edited by lardman: Oct 1 2004, 08:09 AM

[dz]

It's not really a matter of extra work, but more-so a matter of I want to make a way for the zsi2 to be positive of what the program needs. Like you said, what happens if the zsi2 misses the binary and therefore lists no required libs. By having the programmer do it as he's submitting his project and we know exactly what it needs because he tells us.

I do agree with not packaging libs, and as far as I was aware, I didnt know programs actually did package libs alongside.

I dont know if its possible to have a list of libraries by rom but thats would be something similar.

Why can't we simply asking the rom makers what libs they included? Roms are packed tight, and when you're making one, I'd imagine you know practically every piece of software in it.

[dz]

Just wanted to let you all know that I haven't forgotten about this, and I have been working on it. I just finished up the 'add release' portion. I'll explain how it works in detail once I get more done.

I'm hoping to be able to release it for testing soon. I need to add some more error checking to the 'add release' portion, and then i have a small list of things left to do before live release. Live release though will not mean fully functional release. It will simply be to test all the current features and work out the current bugs.

Fully functional release though will be soon

[lardman]

Cool, keep up the good work.


Si

[jamesm]

Well done dz, I'm looking forward to seeing the progress. This is an exciting prospect for Z users everywhere