2012/9/1 Yann Rouillard <[email protected]> > 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
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
