[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are circular dependencies problematic?

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 <rhansen@rhansen.org <mailto:rhansen@rhansen.org>>於 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
    <arnaudr@debian.org <mailto:arnaudr@debian.org>> 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,
Reply to: