The current checksums.ini arrangement has a number of issues: - single monolithic file is a rich source of merge conflicts - concrete URIs require many duplicate entries for different mirrors - can be annoying for folks using overlays and/or collections - storing the checksum separately from the rest of the .bb file makes cherry-picking harder than it needs to be - large amount of churn in checksums.ini can make it hard to spot cases where checksums were changed rather than just added.
It was proposed that, rather than storing checksums centrally in checksums.ini, they should be placed in the individual .bb file to which the checksum relates. Bitbake already has a certain level of support for reading checksums from SRC_URI and it would seem natural to try to make use of that. There was some discussion around alternative proposals of storing the checksums in separate files within the recipes/ directory. These proposals didn't seem to offer any real advantage over storing the checksums within the .bb file (and, importantly, didn't really solve the issues around recipe copying/merging) so they were not pursued further. Some concerns were raised around .inc files and other places where multiple recipes shared a single definition of SRC_URI, but it seems like these can all be addressed with strategic use of variable substitutions. Also, some concerns were raised over the disk space impact of the lengthened SRC_URIs. However, the net increase in disk space usage seems like it will be marginal at worst: many packages will actually wind up using less space with the new arrangement. There was a side discussion around providing a separate mechanism for a site-local cache of checksums, to be used solely for verifying that a particular source archive has not changed from one build to the next. This cache would not be checked in anywhere or distributed. RP noted that this was the original intent of checksums.ini. Agreed to park this for now since it is independent of (though somewhat related to) the topic of shared checksums. Conclusions: - checksums are clearly part of the metadata, it seems like they naturally belong in the .bb file. - there was general acceptance that the checksums belong in SRC_URI. Next steps: - figure out a way to implement sha256sum checking, either by extending the code in bitbake's fetcher or by providing equivalent functionality in base.bbclass - work out a migration strategy: is it feasible to splice the existing checksums into the SRC_URIs programmatically? RP thinks yes. PB suggests leaving the existing checksums.ini as read-only and switching to checksums incrementally for new packages. RP: can make a git hook to allow deletion from checksums.ini but no other changes. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
