Hi!
> > Salsa CI has had for many years the job 'missing-breaks' that
> > complements piuparts by checking that the files a package introduce
> > don't clash with files shipped by any other package in the
> > distribution without having proper Breaks/Replaces in the
> > `debian/control` file. This job works well, being quick to run and has
> > had zero false positives in our experience.
>
> In salsa CI now I see:
>
> $ check_for_missing_breaks_replaces.py -o ${WORKING_DIR}/missing_breaks.xml
> --changes-file ${WORKING_DIR}/*.changes
> [ERROR] Missing Breaks/Replaces found
> [ERROR] runit-init conflicts with init-system-helpers files:
> {'/usr/share/man/man8/invoke-rc.d.8.gz', '/usr/sbin/service',
> '/usr/sbin/invoke-rc.d', '/usr/share/man/man8/service.8.gz'}
> Uploading artifacts for failed job
>
> this looks like false positive, file are in fact diverted. Does the test
> check for for diversions?
No, it does not. This is now tracked at
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/418
The challenge is that most of the debian/ contents is declarative,
such as the file lists in debian-*.install files, while the diversions
are procedural code inside maintainer scripts and challenging to
automatically analyze.
If I get more people interested in collaborating on getting the script
first included in devscripts
(https://salsa.debian.org/debian/devscripts/-/merge_requests/478), we
could later take a stab at adding somekind of diversion detection.
> > ## Schedule
> >
> > 1. March 1st: Enable this job by default, but in allow_failure mode,
> > making Salsa CI yellow on packages that fail on this job
> > 2. March 31st: Remove the allow_failure mode, potentially making the
> > Salsa CI red for packages that fail on this job
>
> Could you please consider delaying 2. until diversion are properly
> detected?
If this CI job is too incorrect for your package, you can also opt out
but having this in your salsa-ci.yml file:
variables:
SALSA_CI_DISABLE_MISSING_BREAKS: 1
The point with having this job enabled for a month in allow_failure
mode is precisely to collect this feedback. If there is enough
packages that use diversions or have other issues, we might indeed
postpone this change, or roll it back completely. Thanks for sharing
your feedback!
