Bug#999505: Discussing possibility of upcoming shirou/disk v2 to v3 transition [was Re: Bug#999505: ITP: golang-github-audriusbutkevicius-recli]
Hello Nicholas, (using my @debian.org mail address) (also my mistake: s/golang-github-shirou-disk/golang-github-shirou-gopsutil/g) On 14/11/2021 01:11, Nicholas D Steeves wrote: > > Oh! Yes, that is a cool idea :-) As far as I can tell, shirou/disk is > only used for free space accounting and blocking updates to shares when > free space is under the configured low-point. Full disclosure: I'm > definitely not a Go expert! In terms of community building, I think > that getting upstream's blessing for this patch, and their view of > regression potential would be valuable. I'm just thinking of how some > upstreams (in general, not Syncthing specific) can be prickly about this > type of patch. In terms of potential regressions caused by this > approach, here is some elided upstream migration info that seems like it > may be relevant: > > [process] RLimit is now uint64 (#364) > [mem] VirtualMemoryStat JSON fields capitalization (#545) > * various JSON field name and some of Variable name have been > changed. see v3migration.sh > [process] process.Status() now returns []string. and status string is > "Running", not just "R". defined in process.go. (#596) > [disk] disk.Opts is now string[], not string. (related to #955) > [disk] GetDiskSerialNumber() is now SerialNumber() and spread to all > platforms > [disk] GetLabel () is now Label() and spread to all platform > [net] Change net.InterfaceStat.Addrs to InterfaceAddrList (#226) > > https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md > This is definitely a good idea. I'll raise an issue upstream to have their feedback and double check to make sure there's no drawback / regression induced by the major downgrade. > Other than that, in a Debian context, we want to avoid a scenario where > all Debian rdeps of v3 reject v3 and patch in support for v2, no? So I > wonder if it would be a good idea to file a bug against lintian to start > checking for this. > Certainly, in the long/mid term, we want to package v3 in order to have latest features and bugfixes. But I'm not sure if a Lintian warning is needed for this? I'm guessing opening bug report on the package still using v2 could be a good idea. >> So I've follow the easiest and less impactful way. We should still bump >> golang-github-shirou-disk to v3 >> later on, but we can take our time (exp upload?) so we make sure we won't >> break anything. >> >> If that's the right approach, then yes starting with an exp upload. I > suspect this may be case where a formal transition is required. > Gradually increasing the severity of the proposed lintian check before > and during this process would give maintainers more time to react (eg: > more friendly and less pushy). > > If there are so few packages depending on v2 that one person can do the > work, then a formal transition may not be required. You wrote "lots of > work", so I'm not sure if it's avoidable. > Here's the rdeps: ``` creekorful@coccia:~$ dak rm -Rn golang-github-shirou-gopsutil Will remove the following packages from unstable: golang-github-shirou-gopsutil | 2.19.11-4 | source golang-github-shirou-gopsutil-dev | 2.19.11-4 | all Maintainer: Debian Go Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: nomad: golang-github-hashicorp-nomad-dev syncthing: golang-github-syncthing-syncthing-dev # Broken Build-Depends: consul: golang-github-shirou-gopsutil-dev golang-github-satta-ifplugo: golang-github-shirou-gopsutil-dev ncbi-entrez-direct: golang-github-shirou-gopsutil-dev nomad: golang-github-shirou-gopsutil-dev (>= 2.18.02~) packer: golang-github-shirou-gopsutil-dev slinkwatch: golang-github-shirou-gopsutil-dev syncthing: golang-github-shirou-gopsutil-dev Dependency problem found. ``` So I guess the job should be doable without doing a 'proper transition' involving the release team & co. The only thing about the rdeps is that they are important packages. >> - Introduce new golang-github-shirou-disk-v3 >>. >>Pros: >>- Don't break anything. >>- Make sure we use the same code as upstream does. >>. >>Cons: >>- Duplicate package on the archive. >>- Make security team work harder. > > I think it's a bit stronger than this ;-) It looks to me like the v2 > branch is most likely now abandonware that, in the future, should be > removed from Debian...but I could be wrong! > Definitely, in the long / mid term this is preferred. >>- Still need to RM old package and make everyone use newest version. >> > > Here's where I have a Golang ecosystem question for everyone reading > this: > > Is there an obvious correct solution based on XS-Go-Import-Path? > eg: Upstream migration instructions says the patch changes from > "github.com/shirou/gopsutil/disk" // to use v2 > to > "github.com/shirou/gopsut
Bug#999505: Discussing possibility of upcoming shirou/disk v2 to v3 transition [was Re: Bug#999505: ITP: golang-github-audriusbutkevicius-recli]
Hi Aloïs, Thank you very much for your analysis. I'm CCing the DGPT (and gopsutil maintainers) so that wiser eyes than mine can spot if either of us missed something; it looks to me like a good plan is emerging. For everyone reading this, I have one big question at "Golang ecosystem" (vis à vis Debian Policy). Aloïs Micard writes: > Actually I have think a bit about it there was another solution: > > Can we downgrade the github.com/shirou/disk version in Syncthing? How much > changes would that induce? The response is: almost nothing. The major bump of > the library haven't change a lot of changes in the way we are using the > module. > > See: > https://github.com/syncthing/syncthing/compare/v1.18.0...creekorful:creekorful/debian-backport > Oh! Yes, that is a cool idea :-) As far as I can tell, shirou/disk is only used for free space accounting and blocking updates to shares when free space is under the configured low-point. Full disclosure: I'm definitely not a Go expert! In terms of community building, I think that getting upstream's blessing for this patch, and their view of regression potential would be valuable. I'm just thinking of how some upstreams (in general, not Syncthing specific) can be prickly about this type of patch. In terms of potential regressions caused by this approach, here is some elided upstream migration info that seems like it may be relevant: [process] RLimit is now uint64 (#364) [mem] VirtualMemoryStat JSON fields capitalization (#545) * various JSON field name and some of Variable name have been changed. see v3migration.sh [process] process.Status() now returns []string. and status string is "Running", not just "R". defined in process.go. (#596) [disk] disk.Opts is now string[], not string. (related to #955) [disk] GetDiskSerialNumber() is now SerialNumber() and spread to all platforms [disk] GetLabel () is now Label() and spread to all platform [net] Change net.InterfaceStat.Addrs to InterfaceAddrList (#226) https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md Other than that, in a Debian context, we want to avoid a scenario where all Debian rdeps of v3 reject v3 and patch in support for v2, no? So I wonder if it would be a good idea to file a bug against lintian to start checking for this. > So I've follow the easiest and less impactful way. We should still bump > golang-github-shirou-disk to v3 > later on, but we can take our time (exp upload?) so we make sure we won't > break anything. > If that's the right approach, then yes starting with an exp upload. I suspect this may be case where a formal transition is required. Gradually increasing the severity of the proposed lintian check before and during this process would give maintainers more time to react (eg: more friendly and less pushy). If there are so few packages depending on v2 that one person can do the work, then a formal transition may not be required. You wrote "lots of work", so I'm not sure if it's avoidable. > The others options were: > > - Bump golang-github-shirou-disk to v3 >. >Pros: >- Only one package on the archive. >- Make sure we are using latest version of the library, with bugfixes and > new features. >- Will also improve the other packages. >. >Cons: >- Lots of work (and syncthing will be RM from testing soonish) >- Possibly lot of breakages, need coordination, etc... > Skip to "Golang ecosystem" for discussion. > - Introduce new golang-github-shirou-disk-v3 >. >Pros: >- Don't break anything. >- Make sure we use the same code as upstream does. >. >Cons: >- Duplicate package on the archive. >- Make security team work harder. I think it's a bit stronger than this ;-) It looks to me like the v2 branch is most likely now abandonware that, in the future, should be removed from Debian...but I could be wrong! >- Still need to RM old package and make everyone use newest version. > Here's where I have a Golang ecosystem question for everyone reading this: Is there an obvious correct solution based on XS-Go-Import-Path? eg: Upstream migration instructions says the patch changes from "github.com/shirou/gopsutil/disk" // to use v2 to "github.com/shirou/gopsutil/v3/disk" thus it seems that XS-Go-Import-Path would need to move from "github.com/shirou/gopsutil" to "github.com/shirou/v3/gopsutil" Then, if https://www.debian.org/doc/debian-policy/ch-sharedlibs.html is applied to Golang -dev packages, then a trip through NEW cannot be avoided, because bin:golang-github-shirou-gopsutil-dev should become bin:golang-github-shirou-gopsutil-v3-dev In light of this, I suspect that packaging NEW src:golang-github-shirou-gopsutil-v3 is the right way forward. > This is certainly opinionated and I'm certainly wrong on certain point, but > that's > how I see the situation. > Thank you once again
Bug#999505: Discussing possibility of upcoming shirou/disk v2 to v3 transition [was Re: Bug#999505: ITP: golang-github-audriusbutkevicius-recli]
Hi Aloïs, Thank you very much for your analysis. I'm CCing the DGPT (and gopsutil maintainers) so that wiser eyes than mine can spot if either of us missed something; it looks to me like a good plan is emerging. For everyone reading this, I have one big question at "Golang ecosystem" (vis à vis Debian Policy). Aloïs Micard writes: > Actually I have think a bit about it there was another solution: > > Can we downgrade the github.com/shirou/disk version in Syncthing? How much > changes would that induce? The response is: almost nothing. The major bump of > the library haven't change a lot of changes in the way we are using the > module. > > See: > https://github.com/syncthing/syncthing/compare/v1.18.0...creekorful:creekorful/debian-backport > Oh! Yes, that is a cool idea :-) As far as I can tell, shirou/disk is only used for free space accounting and blocking updates to shares when free space is under the configured low-point. Full disclosure: I'm definitely not a Go expert! In terms of community building, I think that getting upstream's blessing for this patch, and their view of regression potential would be valuable. I'm just thinking of how some upstreams (in general, not Syncthing specific) can be prickly about this type of patch. In terms of potential regressions caused by this approach, here is some elided upstream migration info that seems like it may be relevant: [process] RLimit is now uint64 (#364) [mem] VirtualMemoryStat JSON fields capitalization (#545) * various JSON field name and some of Variable name have been changed. see v3migration.sh [process] process.Status() now returns []string. and status string is "Running", not just "R". defined in process.go. (#596) [disk] disk.Opts is now string[], not string. (related to #955) [disk] GetDiskSerialNumber() is now SerialNumber() and spread to all platforms [disk] GetLabel () is now Label() and spread to all platform [net] Change net.InterfaceStat.Addrs to InterfaceAddrList (#226) https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md Other than that, in a Debian context, we want to avoid a scenario where all Debian rdeps of v3 reject v3 and patch in support for v2, no? So I wonder if it would be a good idea to file a bug against lintian to start checking for this. > So I've follow the easiest and less impactful way. We should still bump > golang-github-shirou-disk to v3 > later on, but we can take our time (exp upload?) so we make sure we won't > break anything. > If that's the right approach, then yes starting with an exp upload. I suspect this may be case where a formal transition is required. Gradually increasing the severity of the proposed lintian check before and during this process would give maintainers more time to react (eg: more friendly and less pushy). If there are so few packages depending on v2 that one person can do the work, then a formal transition may not be required. You wrote "lots of work", so I'm not sure if it's avoidable. > The others options were: > > - Bump golang-github-shirou-disk to v3 >. >Pros: >- Only one package on the archive. >- Make sure we are using latest version of the library, with bugfixes and > new features. >- Will also improve the other packages. >. >Cons: >- Lots of work (and syncthing will be RM from testing soonish) >- Possibly lot of breakages, need coordination, etc... > Skip to "Golang ecosystem" for discussion. > - Introduce new golang-github-shirou-disk-v3 >. >Pros: >- Don't break anything. >- Make sure we use the same code as upstream does. >. >Cons: >- Duplicate package on the archive. >- Make security team work harder. I think it's a bit stronger than this ;-) It looks to me like the v2 branch is most likely now abandonware that, in the future, should be removed from Debian...but I could be wrong! >- Still need to RM old package and make everyone use newest version. > Here's where I have a Golang ecosystem question for everyone reading this: Is there an obvious correct solution based on XS-Go-Import-Path? eg: Upstream migration instructions says the patch changes from "github.com/shirou/gopsutil/disk" // to use v2 to "github.com/shirou/gopsutil/v3/disk" thus it seems that XS-Go-Import-Path would need to move from "github.com/shirou/gopsutil" to "github.com/shirou/v3/gopsutil" Then, if https://www.debian.org/doc/debian-policy/ch-sharedlibs.html is applied to Golang -dev packages, then a trip through NEW cannot be avoided, because bin:golang-github-shirou-gopsutil-dev should become bin:golang-github-shirou-gopsutil-v3-dev In light of this, I suspect that packaging NEW src:golang-github-shirou-gopsutil-v3 is the right way forward. > This is certainly opinionated and I'm certainly wrong on certain point, but > that's > how I see the situation. > Thank you once again
Bug#999505: Discussing possibility of upcoming shirou/disk v2 to v3 transition [was Re: Bug#999505: ITP: golang-github-audriusbutkevicius-recli]
Hi Aloïs, Thank you very much for your analysis. I'm CCing the DGPT (and gopsutil maintainers) so that wiser eyes than mine can spot if either of us missed something; it looks to me like a good plan is emerging. For everyone reading this, I have one big question at "Golang ecosystem" (vis à vis Debian Policy). Aloïs Micard writes: > Actually I have think a bit about it there was another solution: > > Can we downgrade the github.com/shirou/disk version in Syncthing? How much > changes would that induce? The response is: almost nothing. The major bump of > the library haven't change a lot of changes in the way we are using the > module. > > See: > https://github.com/syncthing/syncthing/compare/v1.18.0...creekorful:creekorful/debian-backport > Oh! Yes, that is a cool idea :-) As far as I can tell, shirou/disk is only used for free space accounting and blocking updates to shares when free space is under the configured low-point. Full disclosure: I'm definitely not a Go expert! In terms of community building, I think that getting upstream's blessing for this patch, and their view of regression potential would be valuable. I'm just thinking of how some upstreams (in general, not Syncthing specific) can be prickly about this type of patch. In terms of potential regressions caused by this approach, here is some elided upstream migration info that seems like it may be relevant: [process] RLimit is now uint64 (#364) [mem] VirtualMemoryStat JSON fields capitalization (#545) * various JSON field name and some of Variable name have been changed. see v3migration.sh [process] process.Status() now returns []string. and status string is "Running", not just "R". defined in process.go. (#596) [disk] disk.Opts is now string[], not string. (related to #955) [disk] GetDiskSerialNumber() is now SerialNumber() and spread to all platforms [disk] GetLabel () is now Label() and spread to all platform [net] Change net.InterfaceStat.Addrs to InterfaceAddrList (#226) https://github.com/shirou/gopsutil/blob/master/_tools/v3migration/v3Changes.md Other than that, in a Debian context, we want to avoid a scenario where all Debian rdeps of v3 reject v3 and patch in support for v2, no? So I wonder if it would be a good idea to file a bug against lintian to start checking for this. > So I've follow the easiest and less impactful way. We should still bump > golang-github-shirou-disk to v3 > later on, but we can take our time (exp upload?) so we make sure we won't > break anything. > If that's the right approach, then yes starting with an exp upload. I suspect this may be case where a formal transition is required. Gradually increasing the severity of the proposed lintian check before and during this process would give maintainers more time to react (eg: more friendly and less pushy). If there are so few packages depending on v2 that one person can do the work, then a formal transition may not be required. You wrote "lots of work", so I'm not sure if it's avoidable. > The others options were: > > - Bump golang-github-shirou-disk to v3 >. >Pros: >- Only one package on the archive. >- Make sure we are using latest version of the library, with bugfixes and > new features. >- Will also improve the other packages. >. >Cons: >- Lots of work (and syncthing will be RM from testing soonish) >- Possibly lot of breakages, need coordination, etc... > Skip to "Golang ecosystem" for discussion. > - Introduce new golang-github-shirou-disk-v3 >. >Pros: >- Don't break anything. >- Make sure we use the same code as upstream does. >. >Cons: >- Duplicate package on the archive. >- Make security team work harder. I think it's a bit stronger than this ;-) It looks to me like the v2 branch is most likely now abandonware that, in the future, should be removed from Debian...but I could be wrong! >- Still need to RM old package and make everyone use newest version. > Here's where I have a Golang ecosystem question for everyone reading this: Is there an obvious correct solution based on XS-Go-Import-Path? eg: Upstream migration instructions says the patch changes from "github.com/shirou/gopsutil/disk" // to use v2 to "github.com/shirou/gopsutil/v3/disk" thus it seems that XS-Go-Import-Path would need to move from "github.com/shirou/gopsutil" to "github.com/shirou/v3/gopsutil" Then, if https://www.debian.org/doc/debian-policy/ch-sharedlibs.html is applied to Golang -dev packages, then a trip through NEW cannot be avoided, because bin:golang-github-shirou-gopsutil-dev should become bin:golang-github-shirou-gopsutil-v3-dev In light of this, I suspect that packaging NEW src:golang-github-shirou-gopsutil-v3 is the right way forward. > This is certainly opinionated and I'm certainly wrong on certain point, but > that's > how I see the situation. > Thank you once again
