Date: Fri, 09 May 2014 22:45:50 +0200 From: John Marino <freebsd.contact@marino.st> To: Doug Ambrisko <ambrisko@ambrisko.com>, marino@freebsd.org Cc: freebsd-ports@freebsd.org Subject: Re: Unable to use ports on 8.3 or earlier since r352986 Message-ID: <536D3E7E.6070209@marino.st> In-Reply-To: <20140509202212.GA39777@ambrisko.com> References: <495738D66545411BA78B31A6615EFA48@multiplay.co.uk> <CAHcXP%2BcyLKCXejUT=A9sGnwGQ-0KfG2VLnzEd79KBGy238=jzQ@mail.gmail.com> <EDCDD12BB5FA4EACA2A91C4A108CAD5C@multiplay.co.uk> <536D05E6.10905@marino.st> <20140509202212.GA39777@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/9/2014 22:22, Doug Ambrisko wrote: > On Fri, May 09, 2014 at 06:44:22PM +0200, John Marino wrote: > | I'll stress the previous point again. The change that broke this was > | desired 8 months ago. It was applied as soon as it was legal to do so. > > FYI, because some might be legal doesn't necessarily make it in the > best interest of users. It should be obvious that nobody breaks trees intentionally for fun. It's done in the overall best interest of users. > | Anyone who knowingly chose not migrate off before the EOL pretty much is > | getting a lesson about why that was an unwise decision. That lesson is > | not specific to FreeBSD. > > There are company's that use FreeBSD as a basis of their product and can't > move quickly and when they move tend to move in big steps. Doing a QA > of a complete OS is expensive and will turn up unknown new problems and > yes fix some as well. However, when you have a large installed base > that is a big risk. So rather then track an 8 -stable release it makes > more sense to focus to co-ordinate a move to 9 release and 10 release. > Once we pick a X.Y release we stick to it and back changes until we > go to a X+1 release. Depending on SW requirements a newer port might > be required. Also some company's depend on 3rd party binary SDK's. We > have binaries running on "unsupported" OS versions but with newer OS kernels. If these companies are going to ignore EOL at their own risk, then they can simply freeze the ports tree and then cherry pick and modify as needed. The release is unsupported. The timeline is published years in advance, so there is no one to blame. If a company's lifeblood is based on unsupported releases, I hope they have post-EOL plans. > The company that I work for is not currently impacted by this but we > might if we have to grab a newer port for an older release of FreeBSD. > > | > Users may well be quite happy to port the small number of OS security fixes > | > until they have completed their upgrades, I know thats something we plan to > | > do here. Ports on the other hand is a different matter, as the number of > | > fixes / changes is much higher so makes it impractical. > | > | They were supposed to have completed their upgrades prior to the EOL. > > It that along the lines of saying that FreeBSD will stop running 4.x > binaries since FreeBSD 4 is not longer supported? That is a value I > find good with FreeBSD that it is some what easy to do ... to make it > work well I have some rtld patches that deal with ports library conflicts > of name/version. No, it's along the lines of saying don't update the ports tree after the release is EOL'd. There is always the option of moving to pkgsrc - although doing so is more disruptive than simply upgrading to release 8.4. > | > One example that springs to mind is the release version of pfsense is still > | > 8.3 so being to still compile updated ports with fixes for that is very > | > useful. > | > | I don't know anything about pfsense, or why it needs to compile ports, > | but I think you should asked them why they haven't had a release prior > | to 8.3 EOL. That's probably an excellent question. > > Maybe they are spending their limited resources on a 10.1 release? > > The point people are raising is that this is breaking things for them > with no easy migration plan except an OS redo of which they might not > have time to qualify to deploy. So then they thing is it time to switch > to a different OS? They didn't get caught with their pants down. Anyone in a bad spot is here as a result of poor planning and switching the OS isn't going to solve that problem. And the length of time FreeBSD provides release support as competitive with just about gratis OS, is it not? John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?536D3E7E.6070209>