[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[britney]: Do you use --control-files or the "legacy package layout" in your derivative?


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 package layout" 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.


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/


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: