On 03/03/2025 20:02, tony mancill wrote:
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: bob...@packages.debian.org
Control: affects -1 + src:bobcat
User: release.debian....@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.

To clarify: the request is useful, particularly at this stage in the freeze. But after the request was approved, there was little for us to do, that's why I closed the bug.

Feel free to reply here if you have issues or questions regarding the transition, or to send us a bug list (e.g. usertagged bugs) for rdeps so that we can take a look at the progress.

Cheers,
Emilio

Reply via email to