On 3/4/26 03:00, Andrew Lee wrote:
On Wed, Mar 4, 2026 at 2:02 AM Arnaud Rebillout <[email protected]> wrote:
I'd think a little code vendoring can be better than a circular
dependency. In this particular case, the maintainer of this package
knows best.
I would like to share my experience when I deal with circular
dependency while updating golang-google-api and go-google-cloud
packages.
1. Use vendoring to bootstrap both binary packages.
2. Put these binary packages into a local repo where allows pbuilder
or sbuild to use.
3. Do the clean and proper way to updating the package without
vendoring but use the local repo in pbuilder or sbuild.
4. Replace the vendoring binary packages with clean packages in the local repo.
5. Rebuild the package with clean binary packages.
This way I can always skip the circular dependency locally. After I
cleanly updated and built the package, do binary upload first and then
source upload.
Thank you all for the information! I opened a merge request for a new
best practice section in
<https://go-team.pages.debian.net/packaging.html> that discusses
circular dependencies:
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/12
A rendered version of that MR can be found by going to:
https://salsa.debian.org/rhansen/go-team.pages.debian.net/-/jobs/artifacts/circular-dependencies/browse/build?job=build
then click on packaging.html, then click on the link on the warning
page, then go to the "Circular Dependencies" subsection.
Reviews would be appreciated.
Thanks,
Richard
Regards,
