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

About golang-github-*-cpuid projects



Hello everyone

Earlier today I filed an ITP [1] for golang-github-canonical-cpuid [2]. I did this after cursory search for the exact import path. Just a moment ago I noticed there are two other cpuid projects: [3] from Intel which canonical has forked as the original project is archived, and [4] from klauspost which seems unrelated in ancestry.

I have a question about the intel and canonical repositories and their subsequent packaging. Since intel has archived development and canonical depends on the library in a product, and is willing to maintain it (however little that is likely to be needed), should we attempt to unify the packaging of the projects somehow?

I reached out to the person maintaining the fork internally at canonical in order to arrange for simple and expected goodies such as: go.mod support, complete the rename in the readme and example, a v1 tag, enabled issue tracker and so on. I believe all of those should happen relatively soon.

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.

Oh and I'd be happy to put the packaging I did to [5] once I'm approved as developer (request sent).

I'm looking forward to your thoughts and opinions.

Best regards
ZK


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113696
[2] https://github.com/canonical/cpuid
[3] https://salsa.debian.org/go-team/packages/golang-github-intel-go-cpuid
[4] https://salsa.debian.org/go-team/packages/golang-github-klauspost-cpuid
[5] https://salsa.debian.org/go-team/packages/golang-github-canonical-cpuid


Reply to: