Hi Emilio,
On Fri, Feb 28, 2025 at 10:12:59AM +0100, Emilio Pozuelo Monfort wrote:
Control: tags -1 confirmed
On 27/02/2025 05:10, tony mancill wrote:
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: bobcat@packages.debian.org
Control: affects -1 + src:bobcat
User: release.debian.org@packages.debian.org
Usertags: transition
Dear Release Team,
The bobcat source package 6.07.01 introduces an enum change that will
require sourceful uploads of a subset of packages that have build
dependencies on libbobcat-dev to accommodate the new enum value. Or put
more directly, the following packages will FTBFS once bobcat >= 6.07.01
enters the archive:
filtermail
flexc++
guncat
natlog
ssh-cron
stealth
xd
In case you're curious, the reason the enum change can't be made
backwards compatible is due to the use of a single precompiled header in
bobcat 6.07 and the preprocessor tripping over the (old) enum value of
"None". Not all
There is no ABI breakage, hence no SONAME bump, and there is no issue
with libbobcat6 entering the archive.
All of these source packages have a common upstream author who has
already prepared updated upstream versions that will declare versioned
build dependencies on libbobcat-dev >= 6.07.01. I have verified the
list by building all packages that build-dep on bobcat.
If the transition is approved, I believe the convention is that I will
file FTBFS bugs against all of the affected build r-deps and block them
with the transition bug. (Or perhaps simply mark these packages as
affected by the transition bug?)
Then upload bobcat to unstable, and follow immediately with the new
versions of the affected packages with the versioned build-dep. This
could also be done in the opposite order - I am open to guidance.
I wasn't 100% clear on how to specify a version in the ben file but this
is the proposed file:
Go ahead. I don't think we need to track this as a transition, as as you say,
there is no SONAME bump. You can just file those bugs, usertag them, and start
fixing them or sending patches, and track the progress in the bug list.
I thought that might be the case for this change, but wasn't 100% sure
due to this statement [1] (since there are patches in this case):
The Release Team considers everything a transition where the upload of
a package requires changes (rebuilds or actual patches) to reverse
dependencies.