[csw-maintainers] Checkpkg test for direct binding

[Maciej (Matchek) Bliziński]

2012/9/1 Yann Rouillard <yann at pleiades.fr.eu.org>

> 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 ?
>

For new packages it'll work, but if you want to check a previously indexed
package, you'll get a crash. It makes sense to check the whole catalog
after adding a new check, because it's useful to analyze already existing
packages for issues we might have previously missed.


>
>
>>
>>
>>>
>>> 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 ?
>

It's been a while since I last did it, so I don't recall all the steps; I
had a shell script to do it. It was calling pkgdb to import packages one by
one, over catalogs one by one. The operation is IO bound I think, so there
isn't much point in making it parallel.


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

Yes, this is a good approach. If you store the data in a way that well
resembles the original structure, it'll be easier to make write future
checks.


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

Sounds good.


>
> What do you think about all this ?
>

We need to plan the database update. The rough outline of steps to take,
from memory:

- increment the data structure version in the code so that checkpkg knows
we're messing with it
- create a new empty database, named checkpkg2 (will be renamed later)
- alter ~/.checkpkg/... config in your home directory to make checkpkg use
the new database (needs to use the relmgr credentials, I'll give them to
you)
- stop the catalog generation to avoid race conditions
- using the new code import the complete catalog into the database
- submit the code into the repository
- send a notification to maintainers@ that people should update the code
and not use the buildfarm for the next 2h or so (to have some margin)
- move the old checkpkg database out of the way, rename the 'checkpkg2'
database to 'checkpkg' (I'm quoting because I mean the literals)
- now people with the old code can't do anything, will be getting error
messages about data mismatches (they shouldn't index new packages and
storing the old data structure, there's a safety check to prevent that)
- people with the new code should be able to work normally
- revert ~/.checkpkg (your homedir only) to the old state (or remove it
altogether)

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120901/e02b13c3/attachment.html>