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 <alois@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
Attachment:
signature.asc
Description: PGP signature