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 <al...@micard.lu> 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 for an excellent and practical analysis. I'm honestly not sure about a Debian-specific patch for Syncthing to stick with v2, but that's just because I'm ignorant about the finer technical points of it. I'm sure I missed something too! This discussion is also a cool opportunity to figure out how https://go-team.pages.debian.net/packaging.html should be updated to deal with this type of case :-D Regards, Nicholas
signature.asc
Description: PGP signature