Zygmunt Krynicki <me@zygoon.pl> 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
Attachment:
signature.asc
Description: PGP signature