Hi, I am writing to you, because I know that you are (or have been) involved in setting up or maintaining a britney instance for a Debian derivative. If you are no longer involving please let me know who to contact instead (where applicable). We are considering to deprecate the "legacy package layout" and remove the "--control-files" option. 1) Debian no longer uses these two features in our production runs at all and now instead simply point britney at the metadata of a standard mirror. 2) The "--control-files" option has not being updated and currently generates incomplete Sources files for the target suite. We have no test cases to safe guard against that. As it is not a feature we use, it is unlikely to appear there. 3) The legacy is currently used for tests and is unlikely to disappear immediately. However, if a better layout for test cases appear, we may migrate to it and remove the old code. How can I tell if I use these features? ======================================= Check your britney command line. If it includes "--control-files" then you are using both features (as "--control-files" only works with the "legacy package layout". Otherwise, check your britney configuration. If the path set for the "TESTING" configuration points to a standard APT mirror (with a Release file) you are unaffected by this mail. If it instead points to a file directory with some "Packages_X" files and a "Sources" file, you are using what I refer to as the "legacy package layout". You can also check the output with -v for a line like [1]. This determine if britney actually believes it is working with a standard mirror layout. If you use "--control-files": ============================= If you use "--control-files", then you can probably discard it. If you rely on the updated target suite, please consider reusing whatever tooling you use to generate your source suite data to also generate the target suite. This ensures you have a sane full data set for both source suite(s) and target suites. If you use the legacy package layout: ===================================== If feasible, consider migrating to using a standard mirror layout (e.g. if you have a local mirror on the machine running britney). This also enables you to remove the "ARCHITECTURES" and "COMPONENTS" fields from your configuration file as britney simply reads those from the Release file of the target suite. If the mirror format it not an option, please let me know about your use case to see if there is a better alternative. Other bits while we are in contact. :) ====================================== Improving britney: ------------------ We are accepting contributions to britney via salsa.debian.org[2] in form of Merge Requests and bug reports via the BTS as usual (with or without patches). Merge Requests are preferred over patches in the BTS as we have configured salsa to run our test suite for britney along with our code coverage report at [3]. More (technical) details can be found in our docs for contribution[4]. Request for info about your britney sources/configs/setups: ------------------------------------------------- We would very much like an updated list of links to your britney sources (e.g. forks/clones), configurations and setups. Our aim is to get a better understanding of what is out there and how you use britney. If you use britney to process data generated by other tools than the ones in use by Debian (like dak), it might be good to mention that as well. Please send this info to debian-release@lists.debian.org. Thanks, ~Niels [1] I: [...] - Found a Release file in testing - using that for defaults (Exact format depends on which version you are using) [2] https://salsa.debian.org/release-team/britney2 [3] https://release-team.pages.debian.net/britney2/coverage/ [4] https://release-team.pages.debian.net/britney2/docs/contributing-to-britney.html