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 <team+pkg-go@tracker.debian.org>
------------------- 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/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"
>
Actually the XS-Go-Import-Path doesn't need to change because it is
resolved to the root of the repository. For example:
- github.com/shirou/gopsutil/disk
- github.com/shirou/gopsutil/foo
- github.com/shirou/gopsutil/bar
modules would all be provided by the root github.com/shirou/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.
>
Actually, what I think feels the best way (opinionated) would be to update
golang-github-shirou-gopsutil to v3 (keeping the same source package)
and then doing an exp upload to looks for breakage and then fixing them
and doing unstable upload. This way we keep only one package in the archive.
Why I haven't choose this way? I guess it's a bit of laziness and the fact that
syncthing will be soon removed from testing and I'd love to prevent that.
But after re-consideration maybe I shouldn't care that much about syncthing being
removed and follow what feels best.
What do others think?
>> 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!
>
I totally agree with you on that one. I prefer not writing patches (especially
that impactful) but I guess I've choose the lazy way (meh) which I now re considerate.
> 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
>
Many thanks for your email and involving the team :)
Cheers,
--
Aloïs Micard <creekorful@debian.org>
GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Reply to: