On 3/4/26 16:20, Andrew Lee wrote:
Hi Richard,
Wow. Nicely hard work. However, the merge request is a bit too long but
without a simple key example to understand even I have been went through
the process for updating -google-api and -google-cloud by myself.
Maybe I'll move the bulk of that new section to an entirely new page
where there is room to do a complete detailed example.
I think it’s best to do a discussion with a small talk to demonstrate
how I did it during mini debconf Hamburg.
Possibly some parts for go packing policy and workflow can be optimized.
A talk and discussion would be great. More experts thinking about how
to improve the workflow is always a good thing.
To be clear, are you volunteering to give the talk and lead the
discussion yourself? Or are you looking for a volunteer?
I would like to update the Go team pages as much as reasonable before
the discussion so that people can reference our latest thinking.
Would that be possible that you or anyone else in the team would like
to join mini debconf Hamburg to discuss and optimize the workflow?
Hopefully we can map it into the documentation for circular build
dependencies together?
Is participation limited to those who can physically attend? If so, I
would not be able to join.
-Richard
Best regards,
-Andrew
Richard Hansen <[email protected] <mailto:[email protected]>>於 2026
年3月4日 週三，21:52寫道：
On 3/4/26 03:00, Andrew Lee wrote:
> On Wed, Mar 4, 2026 at 2:02 AM Arnaud Rebillout
<[email protected] <mailto:[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 <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 <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 <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,
