Wolf480pl
I don't mind Debian having old versions of software.
What I do mind is when it's 2 months until soft-freeze of the next release, and the package in both unstable and testing has same-ish version as the one in stable
even though upstream has had 5 LTS releases since....
To anyone familiar with Debian development: is this a "you can help fix this" type of situation, or is it too late for that?
Haelwenn /элвэн/ :triskell:
Martin Roukala (né Peres)
@wolf480pl Seems like self-inflicted pain on their behalf. I would say if a project uses Go, just go with the flow and use their dependencies... then use this spare time to work on tooling to know when to rebuild packages and bump deps versions.
Wolf480pl
@mupuf idk what was the reasoning of those who decided Debian's policy on packaging golang packages.
I see the appeal of not having 10 different versions of a popular library in your system, even if it's statically linked.
But from a pragmatic point of view, I would just run `go vendor` and treat source code of all the deps as source code of the end-package.
Wolf480pl
@mupuf well actually it's more the 150 dependencies part.
If I only needed to contribute a package for an updated victoria-metrics, I'd try to do that.
But packaging all the go libraries that are needed to build victoria-metrics into golang-*-dev packages looks like a very un-fun chore, and the golang team at Debian probably has a better know-how and tooling to do that in a more efficient way than I would.
Martin Roukala (né Peres)
@wolf480pl Not sure I understand your nvm comment. How does it make it OK?
In my not so humble opinion, if a package is not at the latest version (LTS or not) before a stable release, it should be dropped from the distro since they have no hope of having the bandwidth to maintain the package if they can't even package its latest version.
Wolf480pl
@mupuf it being written in golang makes me utterly unexcited about the perspective of helping with the packaging
Wolf480pl
nvm it's written in golang with a fuckton of dependencies, all of which had their version bumped :/
Martin Roukala (né Peres)
@lanodan @wolf480pl I tend to agree that the Golang philosophy isn't compatible with stable distros'.
But hey, it is also super simple to use ready builds, so Debian just shouldn't bother... or they should treat these packages as a rolling distro would. Wouldn't be hard to create a new repo for that.
Again, all of the pain is self-inflicted and now users are using outdated software by default and upstream is wasting their time documenting how outdated distros packages are... hurray!
Haelwenn /элвэн/ :triskell:
Wolf480pl
@mupuf @lanodan
uhh, idk, for me an outdated version is better than a rolling version.
I sometimes need features that were released last year. But that's only for a single-digit number of packages.
For a majority of packages I have installed, an old version is fine.
And not having breaking changes or new dependencies appear in a minor update is very important to me.
Haelwenn /элвэн/ :triskell:
Wolf480pl
@mupuf @lanodan
oh, also, I've seen a few of the "cloud infrastructure" type of projects start providing LTS releases, or increase the length of bugfix support, in the last few years, presumably as a result of pressure from big companies who use those. If this trend continues (which I hope it will), we may see the day when those projects can be included in Debian the normal way :D
Haelwenn /элвэн/ :triskell:
@wolf480pl @mupuf Well Alpine does new release every 6 months but they're supported for 2 years, so to me it's the best of both worlds.
And typically I just have to do a apk update && apk upgrade, there's only very few cases where I can end up holding on a specific release.
Wolf480pl
@lanodan @mupuf
for me, 6 months is a blink of an eye... I can easily lose motivation to work on my home server for that long, and if I come back only to find out that now I need to update by two versions instead of one, I'm gonna quit.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.