[csw-maintainers] Checkpkg test for direct binding

[Yann Rouillard]

Hi Maciej,


>> What are the cases where the new checkpkg code is called on an older
>> structure data ?
>>
>
> This will happen immediately after someone checks out the updated code.
>

When I recompile a package with my code, it seems to update the data on my
package and I don't have errors about that.
What do I get wrong ?


>
>
>>
>> I can easily ignore the test if needed_symbols is not present. What is
>> your advice ? Is is costly to reindex all packages ?
>>
>
> Costly - yes, but it's a one time operation. I've done it a couple of
> times already. It can be done in parallel with normal operation; you import
> into a new database, and then you swap databases together with checking in
> the code.
>

Ok, how and when can we do this ?

Before I may want to do some changes in the way the data are stored.
Currently I store them in a dictionnary with the soname as the key. The
problem is that this information is not always present in binaries. I only
know they are at least present if direct binding is enabled.
As I wanted to check if direct binding was enabled, this was not a problem
but I wonder if it wouldn't be a better to store the list of symbol as a
simple list contains for each symbol the name of the symbol, the soname and
version interface providing it if available.

This will take more space in databases (and in rest transfers) but if for
some reasons, we need to add some checks which just are interested in
symbol presence, they would work whether direct binding is enabled or not.

I also wonder if we should use "elfdump -v" rather than "dump -Lv" to
extract soname needed as we get in addition the version information of the
soname with elfdump. That would allow us to easily add a check to make sure
our binary don't work only on the last solaris update.

What do you think about all this ?

Yann





Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120901/45af0e77/attachment-0001.html>