[csw-maintainers] Checkpkg test for direct binding

Maciej (Matchek) Bliziński maciej at opencsw.org
Sat Sep 1 22:32:37 CEST 2012

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

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

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

More information about the maintainers mailing list