Hi - > [...] > Every time you rebuild some packages, the package files are rebuilt with the > new contents. When this happens, the new package files will have a newer > mtime, but the files inside the archive (elf, source) will have the same > fixed timestamp as before.
Do I understand this part correctly: that yocto package-file filestamps are normal (reflect their actual unique-ish creation time), but the timestamps of constituent files are synthetic (and may be backdated / duplicate)? > And when debuginfod will traverse them (without the patch I > propose), it will not update the database because it will find > consider that the files inside the packages were not modified. [...] That's not how debuginfod works though. It decides to reanalyze archives based on the archive mtime, not the constituent file mtime. Your patch only affects the "_r_seekable.mtime" column, which I believe is not used for any sort of caching/invalidation type logic. > [...] That's the problem I'm facing where, before my patch, the > only thing I could do was to remove the sqlite debuginfod database > and index all again every time I rebuild a package in the yocto > distribution, to have debuginfod serving the new debuginfo > correctly. Yeah, that shouldn't be necessary. Maybe we could make this discussion more concrete by having you show us an actual example. Two different yocto package versions, with detailed timestamp/content listings, ingested into an otherwise empty debuginfod database one at a time, and doing a database dump after both completed scan operations. - FChE
