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.
## Error examples
Example output when end users run into this category of issues:
$ apt upgrade
...
Unpacking example (from .../foo_1.0-1_all.deb) ...
dpkg: error processing /var/cache/apt/archives/foo_1.0-1_all.deb (--unpack):
trying to overwrite '/usr/share/man/man8/example.8.gz', which is also
in package bar 2.2
Example output from the job on failure:
$ check_for_missing_breaks_replaces.py -o
${WORKING_DIR}/missing_breaks.xml --changes-file
${WORKING_DIR}/*.changes
[ERROR] Missing Breaks/Replaces found
[ERROR] foo conflicts with bar files: {'/usr/share/man/man8/example.8.gz'}
On Tue, 2025-02-25 at 08:14:52 -0800, Otto Kekäläinen wrote:
$ check_for_missing_breaks_replaces.py -o…and this advice, are not ideal, and can lead to potentially worse problems.
${WORKING_DIR}/missing_breaks.xml --changes-file
${WORKING_DIR}/*.changes
[ERROR] Missing Breaks/Replaces found
[ERROR] foo conflicts with bar files: {'/usr/share/man/man8/example.8.gz'}
I think the check should be renamed to something like
check-file-conflicts (probably with compat names for existing repos
using the old name). And the advice should probably point to a Wiki
page or similar, where the various cases can be explained, and how to
solve them. For example for conflicting programs with different
interfaces the advice would incur in a policy violation, for conflicts between a current shared library SOVERSION and the one in the archive
with a lower SOVERSION that makes upgrades and transitions harder,
etc.
[ERROR] You might want to rename/remove the offending files if that'ssuitable
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.
## 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
Hello Otto,
[please keep me in CC, I'm not subscribed]
Salsa CI has had for many years the job 'missing-breaks' thatIn salsa CI now I see:
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.
$ 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?
## ScheduleCould you please consider delaying 2. until diversion are properly
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
detected?
Best Regards,
Lorenzo
Another instance of diversions not being detected is in linux's pipeline [1,2]: linux-libc-dev and oss4-dev both install /usr/include/linux/soundcard.h, oss4-dev diverts it, missing-break fails. If my understanding is correct, this will make all unstable/exp (oss4-dev is in unstable only) src:linux pipelines break starting March 31st.
oss4-dev is fine (unless diversions of files in linux-libc-dev are forbidden): oss4-dev is correctly diverting the header, as a consequence it needs not Break or Conflict with linux-libc-dev.
The issue here is that the new missing-breaks pipeline job has no clue that packages are correctly diverting files, and it flags as missing Breaks packages which, in fact, do not miss Breaks because they aren't supposed to have any.
However, I'm reasonably certain that there are other cases where diversions are intentional and perfectly valid. Unless 'missing-breaks' learns to
handle them it will report CI failures for *all* of them, at which point we might as well change Policy to state that diversions are a legacy feature that cannot be used in new uploads.
I kindof doubt that we'd get a majority to sign off on that.
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?
## 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?
^^^^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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 40:03:40 |
Calls: | 10,392 |
Files: | 14,064 |
Messages: | 6,417,198 |