On Tue, Jul 29, 2025 at 9:38 AM Jochen Sprickerhof <[email protected]> wrote:
> I failed to reproduce this. I did: > > gbp clone vcsgit:golang-github-golang-protobuf-1-5 > cd golang-github-golang-protobuf-1-5/ > dch -i '' -D unstable > git deborig > sbuild > cd .. > mmdebstrap --customize-hook='copy-in \ > golang-github-golang-protobuf-1-5-dev_1.5.4-1.1_all.deb \ > protoc-gen-go-1-5_1.5.4-1.1_amd64.deb /opt' \ > --chrooted-customize-hook="set -x ; apt -y install \ > golang-github-denverdino-aliyungo-dev apt-utils && cd /opt && \ > apt-ftparchive packages . > Packages && \ > apt-ftparchive release . > Release && \ > echo 'deb [trusted=true] file:///opt ./' >> > /etc/apt/sources.list && \ > sed -e s/bookworm/trixie/ -i /etc/apt/sources.list && \ > apt update && apt dist-upgrade" bookworm /dev/null > > And I still get: > > The following packages have been kept back: > golang-github-denverdino-aliyungo-dev > I'm afraid you are correct, I am able to verify that the package is being held back. I guess you are right, and in order to avoid having these held-back packages, we would have to remove [email protected] completely out of trixie by adding a transitional dummy package. My concern about that is that software that hasn't been updated to 1.5 would break at build or runtime. Is that a risk we want to take that late in the cycle? I wonder whether some documentation in the release notes wouldn't be the more prudent approach. Release team, please advise what path is more appropriate for trixie. -rt -- regards, Reinhard
