Just upgraded my dev machine to Ubuntu 23.10 and checked the syncthing version provided by their universe repo out of curiosity:
syncthing/mantic 1.19.2~ds1-3 amd64
Jesus. That version even predates the last Ubuntu LTS release by two weeks.
Unfortunately, Debian is stuck with an equally outdated version.
Nice.
I don’t think this has anything to do with Canonical or Ubuntu. They just ship the exact same packages as Debian for syncthing.
Looking at Debian’s upload activity, it appears as if uploads of new versions to unstable are made very infrequently: Debian Package Tracker
A bug report requesting an update to 1.23.6 or newer has been left unanswered: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042364
For what it’s worth, but I replied to the QUIC bug that upgrading syncthing would save them future headaches. The quic-go version we’ve been using since v1.24.0 shouldn’t break with every new go version.
At least for debian, the problem here is not the version in their repos, it’s what distro one uses: If you want up-to-date packages, debian isn’t the distro to use. I have no clue what the ubuntu philosophy is, I never quite understood how the biggest distro can be based on snapshots at random times of the “testing” suite of debian. Clearly that implies either a crapton of work for ubuntu maintainers or a somewhat bad state - seems like it’s something in between.
tl;dr: No point in complaining about syncthing versions in debian/ubuntu, if you want up-to-date versions, use syncthing’s distribution channels or a rolling/bleading-edge distro.
2 Likes
Clarification: Debian is not a distro. It is a project which have several distros: Stable, Testing, Unstable. They have different goals and use cases. (I don’t intend to start a discussion, just want to bring some facts to the table.)
Yes!
I wouldn’t complain about Debian shipping older releases if these versions would somehow line up with their own schedule. But even Debian unstable still points to the ancient v1.19.2.
I don’t know about what exactly is termed a “distro”, my point is that debian has releases, those have numbers, nicks and designations like stable, old-stable, old-old-stable, … - testing and unstable (and experimental) aren’t that. They are development suites to reach the next such stable release. They may be used by end-users (I have run testing as my daily driver until recently, it’s mostly stable), but they are not meant to do that. And definitely do not provide any guarantee or even have the goal to ship the latest software.
There’s no unstable schedule. You will be able to rightly point out (you never get to complain) that it’s out of date if it doesn’t get updated in time for the freeze of the next stable release (it usually does - compare v1.19.2 to the time the last debian release was frozen).
1 Like
You’re right, but the point is: Not even Debian Unstable gets new syncthing versions. The usual debian-way is to upload new versions of packages into unstable “right away”, after upstream releases them. Once they have slightly “stabilized”, packages move into testing. And once every two years, testing becomes stable.
This is slightly simplified, since there are also freezing periods where nothing is uploaded to testing + unstable, but the current freeze has ended and uploads to unstable are open. Yet the most recent syncthing version in unstable is years old. If unstable doesn’t get fresh versions on a regular basis, testing will lag behind, which in turn can cause stable to become ancient.
The most recent Debian stable (bookworm) was released on June 10th, 2023 (not counting point releases). The syncthing version shipped with Debian bookworm was released in ~March/April 2022. The freeze relevant for bookworm did not start before February 2023 (full freeze in May 2023) - at the very first freeze point, testing + unstable was already lagging behind for ~1 year.
1 Like
I suspect that part of this is that pushing a new Syncthing release to Debian is quite involved. The way they handle source packages, for philosophical reasons, means it’s far from just dropping in our latest tarball and pushing. I could offer my opinion on all this, but it doesn’t really matter - they do what they do for solid reasons, and we enjoy the fruits of that work…
6 Likes
The Debian maintainers do a solid job. The word “complaining” doesn’t really describe it.
I’m more interested in why it’s outdated. Do they lack resources and are backlogged? Is it a general problem with Go-based software? Or are some of our dependencies causing them headaches?
That’s my line of thought as well.
Of course it’s resources: Debian is volunteer run (with some people being sponsored to work on it, but that’s the excemption) and packaging is work. Even more so in debian which doesn’t always (often) take the easiest/most straight forward path, for a variety of reasons (license, technical, social, …). Anyway, there doesn’t seem to be much willingness to accept the point that it isn’t outdated in the actual debian release, which is what counts from the pov of debian, so I’ll try another pointer: Syncthing in debian is maintained by the go team not a single maintainer, packaging happens in the open in git - you can go there, learn about the packaging and contribute - team members are friendly and very happy about helping hands.
(Damn I am procrastinating heavily atm - this thread is a way too tempting: xkcd: Duty Calls)
6 Likes
FWIW, Debian “Testing” (currently Trixie) is mentioned as one of the better “rolling release” distros in a lot of the lists of them that I’ve seen…
I’ve been running various Debian releases for years, and since I’ve been running ST, I have found the method of adding the ST repo to the Deb sources list, works just fine. Just follow the directions in the ST docs on how to do it.
I don’t see that having an older ST version in the Debian repo is a big problem - just an annoyance…
I don’t know (or care) what Canonical does…
ex-Gooserider