Depending on how fancy you want to be with pulling some tricks in the deb, you could also:
1. Use provides, set up some simlinks and sed action, and file a RM 2. Take over the binary package and build something from the new sources under the old name I haven't looked into doing this with a go dev package yet though, so grain of salt etc - I've spent zero time thinking about this critically Paul :wq On Mon, Sep 1, 2025, 2:22 PM Simon Josefsson <[email protected]> wrote: > Zygmunt Krynicki <[email protected]> writes: > > > With this in place, is there a mechanism where one of the packages > > could be sunset and replaced by the other? Is that desirable? I think > > the go module replacement functionality can do it at the go level and > > something similar is technically doable at package build time. > > Not really, I think the best we have is something like this: > > 1) Get golang-github-canonical-cpuid into Debian. > > 2) Update all reverse build dependencies of golang-github-intel-go-cpuid > and golang-github-klauspost-cpuid to use golang-github-canonical-cpuid > instead. > > 3) Ask for removal of golang-github-klauspost-cpuid to use > golang-github-canonical-cpuid. > > That may appear simple, but there are traps including: > > A) Instead of patching projects directly, we should really ask upstream > to change and use the new project. This introduce 1) delays, possibly > many months, and 2) risk that upstream refuses because of Reasons and > sometimes they are good and sometimes they are bad. I've done this a > couple of times, and sometimes upstream comply but it has happened > several times that they did something else instead, sometimes reasonable > and sometimes problematic. > > B) There may be subtle API/ABI differences between the projects, are you > sure your project is a full superset of the earlier ones? > > C) For how long will you maintain your version? If one of these > packages have been around for 5-10 or more years and worked fine, we as > external people may rightly wonder if your new shiny project won't just > end up in the same shape 5-10 years down the line. So please consider > if you can't just make one of the existing project work for you instead > of creating another project. > > People have different preferences and thinking on these topics. I > prefer to package what upstream ships if it can be made to work, and to > report wishes on upstream to them and let them decide. This leads to > slow results, which sometimes frustrate. > > /Simon >
