Havard Eidnes <h...@netbsd.org> writes: >> I think I may have struck a nerve. > > I'm not sure I understand what that's getting at. It's not a > particularly "sensitive topic" to me or us in general, I would > think. The fact that english is a second language for me may > prevent me from interpreting this comment appropriately.
I don't think 'struck a nerve' fits either. We aren't upset that Don is choosing to run old software. We're just pointing out that it has issues and recommending upgrades. And saying that we are done with 8, so we're not going to spend time helping. It doesn't bother me at all that someone is running 8.2. I am only bothered if they demand that others make things work anyway -- and that's not happening in this case. >> The consensus is that 8.2 is very old and I should upgrade. As of today, it is formally desupported by NetBSD. >> As a software developer, I understand completely. >> >> As a lowly user, I never want to upgrade *anything* that is >> working - ever. (You _never_ trade non-working for working, you >> trade the old bugs for a new set of bugs. ;-> ) Then why aren't you using the packages from when you first installed your 8.2 system? The problem is that you want some old software and some new software. It's fine to want new software -- in fact I'd say it's not good to keep running unmaintained software. There's a parallel in the GNU/Linux world where people run "LTS" that has a very long lifetime, which I describe as "intentionall deciding to run old software". Free Software licenses give people the right to make this choice, and just like GNU/Linux LTS you are welcome to run 8.2, or really even 1.6.1 :-) But often people, having chosen LTS, want to build new software on that old system, and this is not only logically inconsistent with their LTS choice, but tends to run into trouble. A fairly large number of these people expect the current releases of packages to build on their ancient systems. By ancient, I mean "snapshots of 2014". This causes problems for people that maintain software (the upstream maintainers). In pkgsrc, I take the view that if the upstream code doesn't build on a platform when a human follows the upstream build instructions, that's not a pkgsrc bug, but an upstream bug. Certainly we have a lot of workarounds for such bugs, but they are supposed to be filed upstream. For me personally, I gave up on 8 about a year and a half ago, and will likely have given up on 9 within a year. That doesn't mean pkgsrc will formally desupport it -- just that I won't be helping in any signifcant way, other than to add cautions to release notes that people using 9 are likely to have problems.
