Re: PHP version retirement
Am 12.08.2019 um 08:55 schrieb Wolfgang Zenker: * Kevin Oberman [190812 01:50]: On Sun, Aug 11, 2019 at 4:23 PM Martin Waschbüsch wrote: Am 11.08.2019 um 23:31 schrieb Wolfgang Zenker : * Martin Waschbüsch [190811 20:41]: [..] You could also have used the quarterly branch, which keeps software till the end of the quarter. In the case of php 5.6 it would have given you time until March 31st, and would have included version 5.6.40 5.6.40 never made it into the main ports tree. Are you sure it was available in the quarterly snapshot? I am sure. You can check for yourself using the svnweb interface at the FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th Thanks, Wolfgang, for pointing that out. Up to now I always thought of quarterly as a static snapshot of the main ports tree made at a given point in time. No, quarterly gets security fixes, just no "feature updates". That's why we use it in production, so we have to handle potentially breaking changes only once a quarter. OK. Where did 5.6.40 come from? I just looked at the ports repo and it was NEVER committed there. The very last commit to ports/head/lang/php56 was 5.6.39. Whil it has no impact on me, I find it very odd to find a package that never existed in ports. That makes it impossible for me to access the source for this package and recreate it for any reason. My gut feeling is that this is broken and should never happen. It was committed on the 2019Q1 branch only, because HEAD didn't have the php56 port anymore at that time. See here: https://lists.freebsd.org/pipermail/svn-ports-branches/2019-January/006568.html ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Martin Waschbüsch wrote on 2019/08/16 09:27: Thank you for your input. While I agree that PHP, in general, has been and still is a source of lots of security issues, I do not think this is the central point in this debate. There might be a high probability of security issues that are PHP related for all I know, but again, the real question is: Why drop a package that has just had recent security updates after a couple of weeks? I pointed out that I do not think lack of upstream development is in and of itself sufficient grounds for doing so. At the very least, while it may be unwise to use a now obsolete version of PHP, I doubt if an argument along the lines of 'We removed this from ports. It's for your own good' is a very good one. (For a number of reasons). +1 The only other arguments I got so far seem to be about resources. I can understand that. With limited resources you have to prioritize and something will have to give. Now, in a reply to Adam, I asked specifically if there were pointers that would help me evaluate how much effort is really involved. (My working theory being that I so far underestimate the work required to do this.) The effort to keep 5.6 in a tree for a few more months would be ... very little. It was done in quaterly branch after 5.6 was removed from head branch. I did my own updated version of the port (and extensions) from 5.6.39 to 5.6.40 without any issues - running on couple of machines till this day. Also, I asked if people were open to letting a group of people interested in doing so continue to maintain an old version of php so that it does not have to be removed from ports. Kurt suggested that as a feasible way forward and I agree. Earlier, Adam seemed open to discussing a way forward as well, but I am not sure that still is the case. Since I do not yet feel comfortable that I correctly estimate the amount of work, if enough people can be found to volunteer for this, but I remain hopeful. All this notwithstanding, would you be willing to exchange hints & ideas about securing (as far as possible) PHP setups some more, off-list? I'd like to ask some more about your approach. You can put webserver, or just php-fpm inside jail and then just nullfs mount the directory tree with websites on partition with noexec mount flag .. to name a few. Kind regards Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi Dan, > Am 16.08.2019 um 08:07 schrieb Dan Mahoney : > > Martin and others, > > I don’t have a good answer for this, other than to say that PHP has been the > bane of my existence for a while. As a admin, I’ve lost more hours and sleep > on PHP scripts than any other tool. PHP is the programming language that > brought us WordPress, MovableType, PHPNuke, PostNuke, PHPBB, and Drupal. And > I’ve had users running sites with all of them. Shoddy security code and all. > > The “best” way for running PHP (with the privileges of your webserver, as an > apache module) was a security nightmare, and burned me badly. > > PHP’s own builtin security “features” (for example, open_basedir or safe > mode) fail to do what they want to do (and much canned code refuses to work > with them turned on), while things like allow_url_fopen enabled by default > have made even the simplest php-based homepage (where PHP is used as little > more than a repacement for mod_include) vulnerable to reflection attacks. > > Lots of php-based code also has had a horrible history of version upgrades. > > Upgrading PHP burned me badly as well, as code would mysteriously break on > shared hosting systems, and my users would complain about things breaking > overnight, or errors being sent to stdout (i.e. the browser). The PHP devs > would randomly deprecate functions, which would break otherwise-working older > code. > > Let me give you one simple example: Gallery. Gallery 1, which doesn’t > require a database backend. There’s no real good replacement I’ve found for > it, but it’s coded in a hard to read/upgrade style. I’ve secured it by > disabling comments, as well as limiting access to the login/admin functions > with additional .htaccess restrictions, as well as carefully monitoring the > logs and file sizes. > > The solution I ultimately arrived for keeping php both current *and* > compatible was that using SuPHP, I can enable multiple versions of PHP to run > concurrently, even back to php4, as well as limiting the permissions php > scripts have down to the owner, so that each site/vhost has its own php.ini, > users, and permissions. I get here by building php’s CGI/CLI versions from > scratch, and keeping copies of my ./configure arguments handy for each > version, so I can easily rebuild them all if there’s a shared library change. > This also lets me easily swap in PHP versions to test if something will > break, rather than replacing/upgrading the one ports installs. > > Sent from my iPad Thank you for your input. While I agree that PHP, in general, has been and still is a source of lots of security issues, I do not think this is the central point in this debate. There might be a high probability of security issues that are PHP related for all I know, but again, the real question is: Why drop a package that has just had recent security updates after a couple of weeks? I pointed out that I do not think lack of upstream development is in and of itself sufficient grounds for doing so. At the very least, while it may be unwise to use a now obsolete version of PHP, I doubt if an argument along the lines of 'We removed this from ports. It's for your own good' is a very good one. (For a number of reasons). The only other arguments I got so far seem to be about resources. I can understand that. With limited resources you have to prioritize and something will have to give. Now, in a reply to Adam, I asked specifically if there were pointers that would help me evaluate how much effort is really involved. (My working theory being that I so far underestimate the work required to do this.) Also, I asked if people were open to letting a group of people interested in doing so continue to maintain an old version of php so that it does not have to be removed from ports. Kurt suggested that as a feasible way forward and I agree. Earlier, Adam seemed open to discussing a way forward as well, but I am not sure that still is the case. Since I do not yet feel comfortable that I correctly estimate the amount of work, if enough people can be found to volunteer for this, but I remain hopeful. All this notwithstanding, would you be willing to exchange hints & ideas about securing (as far as possible) PHP setups some more, off-list? I'd like to ask some more about your approach. Best, Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 13.08.2019 um 08:13 schrieb @lbutlr : > > On 12 Aug 19, at 01:04 , Martin Waschbüsch wrote: >> So, I find it wrong to say, as I understood you, to remove a package from >> the ports tree because otherwise others people, for instance users of >> FreeBSD, would have the *expectation* of receiving support for those >> packages. > > There is not expectation that any code is being maintained, but there *IS* an > expectation that the software in ports is being maintained, supported, and is > functional. Agreed. But in which areas would you expect there to be problems for a package that was working up date x, got security and bug fixes until date x and the actual source code of which will not change after date x? The only things that come to my mind are changes in packages it depends on or changes in the base os. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On 12 Aug 19, at 01:04 , Martin Waschbüsch wrote: > So, I find it wrong to say, as I understood you, to remove a package from the > ports tree because otherwise others people, for instance users of FreeBSD, > would have the *expectation* of receiving support for those packages. There is not expectation that any code is being maintained, but there *IS* an expectation that the software in ports is being maintained, supported, and is functional. -- Im finding's you'r mis'use of apostrophe's disturbing. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sat, 10 Aug 2019 13:22:25 +0200 Kurt Jaeger wrote: > Hi! > > [...] > > Would it not be better to have, say, the last two versions before > > current stable still in ports but with a huge disclaimer saying: > > use at your own risk, etc.? > > > > What do y'all think? > > You make the case for something other systems call backports, > basically, keeping stuff in working order in the tree. > > Backports in other systems need someone to take up stewardship. > > So, either a group steps forward and takes responsibility to > keep them in working order in the generic tree, e.g. by > - having a mailing list, e.g. backports@, > - and changing the maintainer from ports@ to backports@ > - and fixing PRs as they come up > > Or a group provides their own pkg repo that the normal pkg-user can > reference to retrieve those older packages. > > Both approaches sound possible, but need a non-trivial amount of > investment. > Just wishing one day someone come up with it... I do more and more builds from souce last years because more and more ports disappearing due to deprecated dependencies or themselves (last time it was Natron->qt4 for ex.) what's about php5.6, it isn't big deal to me to build it from source, but if I'll ask people from low budget hosting companies around "Why not FreeBSD?", I think this will be one of significant points, cause many of them hire low-budget engineers, who only can or want install something from ready distro/packages and copy pre-written configs. But maybe FreeBSD indeed isn't right OS for them. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi Adam, > Am 12.08.2019 um 15:29 schrieb Adam Weinberger : > > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch > wrote: >> Furthermore, the argument that it is more more work to maintain an >> abandoned version is silly because it’s more work to delete a port that >> to just keep it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I do not understand this. At all. And I sort of hope I misunderstood you, because it sounds like you think a maintainer is or may be regarded as someone who can be expected to provide product support of some kind? I find that notion worrying to say the least. >>> >>> If you believe that handling updates, analyzing submitted and upstream >>> patches and development, and answering a bevy of questions for every >>> major update is effortless, then you drastically underestimate the >>> amount of work that goes into the ports tree. >> >> You completely misunderstand me. >> I know there is a lot of effort going into this. I disagree only in that I >> do not believe there should be any expectations towards maintainers. >> It is voluntary work. Spare time, etc. I am grateful for the effort people >> put into this, but I strongly believe no one should act towards volunteers >> with any expectations as to what they should do, how much time they spend, >> etc. >> >> So, I find it wrong to say, as I understood you, to remove a package from >> the ports tree because otherwise others people, for instance users of >> FreeBSD, would have the *expectation* of receiving support for those >> packages. >> That perception of any kind of entitlement towards volunteers is wrong, IMHO. >> >> And that is why I answered that part of your message because it is not (for >> reasons stated above) a valid argument against having outdated software in >> the ports tree. > > Ah! You're right, I did completely misunderstand you. > > You're correct that we don't provide any semblance of support for the > upstream software. Absolutely, and under no circumstances should > anyone have to. got it. I am glad that we are on the same page here. > I'm referring to support of the port itself. Maintainership requires > responding to private emails asking for help; evaluating, testing, and > approving submitted patches; responding to PRs about changes or fixes > or poor behaviour (90% of the time related to portmaster); responding > to error reports; and so on. Understood. If I wanted to offer my help maintaining a no longer supported version of php, where would I look to try and identify the amount of work likely to be involved? Would bugs.freebsd.org be a comprehensive source for such an evaluation? There are a total of 10 issues in 2018 and 2019 when searching for php 5.6: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open___status=__closed___status=New_status=Open_status=In%20Progress_status=Closed_status=UNCONFIRMED=OP=OP=OP=product=component=alias=short_desc=CP=CP=product=component=alias=short_desc=CP=CP=OP=OR=OR=substring=substring=substring=substring=substring=substring=substring=substring=substring=substring=changeddate%20DESC%2Cpriority%2Cbug_severity_format=advanced=5.6=5.6=5.6=5.6=5.6=php=php=php=php=php I assume there is more work involved (at the very least compiling php and all its modules with poudriere, for different platforms and / or versions of FreeBSD, etc.). > We do expect those things from maintainers, because those are what are > required to keep the ports tree running. And we actively drop > maintainership from ports where maintainers routinely ignore those > responsibilities, regardless of whether they have a commit bit. Also understood. I took up maintainership of archivers/lz4 a while back when it was without a maintainer, so I am a little familiar with how this works. > As decke noted, maintainership of a small port with relatively low > deployment is pretty smooth (and don't get me wrong, they're as or > more important than the big packages). But a huge and complex > framework like php is a massive undertaking, with a near-constant > barrage of complex patches that require highly complex testing > strategies, and thousands of dependent ports to worry about for every > change. Would you agree that in the case of software that is no longer maintained upstream, the support would mostly consist of ensuring the packages still compile on newer versions of FreeBSD or reacting to problems arising when dependencies for php change? After all, new releases or patches from upstream are no
Re: PHP version retirement
> On 12. Aug 2019, at 16:29, Adam Weinberger wrote: > > On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch > wrote: >> Furthermore, the argument that it is more more work to maintain an >> abandoned version is silly because it’s more work to delete a port that >> to just keep it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I do not understand this. At all. And I sort of hope I misunderstood you, because it sounds like you think a maintainer is or may be regarded as someone who can be expected to provide product support of some kind? I find that notion worrying to say the least. >>> >>> If you believe that handling updates, analyzing submitted and upstream >>> patches and development, and answering a bevy of questions for every >>> major update is effortless, then you drastically underestimate the >>> amount of work that goes into the ports tree. >> >> You completely misunderstand me. >> I know there is a lot of effort going into this. I disagree only in that I >> do not believe there should be any expectations towards maintainers. >> It is voluntary work. Spare time, etc. I am grateful for the effort people >> put into this, but I strongly believe no one should act towards volunteers >> with any expectations as to what they should do, how much time they spend, >> etc. >> >> So, I find it wrong to say, as I understood you, to remove a package from >> the ports tree because otherwise others people, for instance users of >> FreeBSD, would have the *expectation* of receiving support for those >> packages. >> That perception of any kind of entitlement towards volunteers is wrong, IMHO. >> >> And that is why I answered that part of your message because it is not (for >> reasons stated above) a valid argument against having outdated software in >> the ports tree. > > Ah! You're right, I did completely misunderstand you. > > You're correct that we don't provide any semblance of support for the > upstream software. Absolutely, and under no circumstances should > anyone have to. > > I'm referring to support of the port itself. Maintainership requires > responding to private emails asking for help; evaluating, testing, and > approving submitted patches; responding to PRs about changes or fixes > or poor behaviour (90% of the time related to portmaster); responding > to error reports; and so on. > > We do expect those things from maintainers, because those are what are > required to keep the ports tree running. And we actively drop > maintainership from ports where maintainers routinely ignore those > responsibilities, regardless of whether they have a commit bit. > > As decke noted, maintainership of a small port with relatively low > deployment is pretty smooth (and don't get me wrong, they're as or > more important than the big packages). But a huge and complex > framework like php is a massive undertaking, with a near-constant > barrage of complex patches that require highly complex testing > strategies, and thousands of dependent ports to worry about for every > change. Sure, if you feel like that is so there is no need to argue about it. I still feel the latent drift of “php is high profile and low profile is easy” like a sneaky way out of a fruitful discussion ignoring the request made by users: don’t kill software on tight schedules if there is no technical need for it. Unless you want to state a valid technical reason. For PHP 5.6 removal especially one has to assume that general arguments are merely made up here to fit the general lack of disagreement on the grace period issue. That’s fine and easier to say you don’t want to do it vs. it cannot be done. :) > I suggested that it might be possible for stale languages to remain in > the tree, as long as the above support wasn't required or expected. > But, honestly, Franco's response mocking the offer made my desire to > help him somewhere at or below zero, and has pretty much ensured that > nobody else in portmgr is going to be eager to get skin in the game. I‘m merely pointing out you‘re unwilling to do it and your offer was impractical for users running any PHP extension but you were not straight forward in your answer previously. This segment at least makes it clear so thank you for being frank about it. To sum it up there is no desire by maintainers to do what users requested here so yay for that conclusion at least. Cheers, Franco ___ freebsd-ports@freebsd.org mailing list
Re: PHP version retirement
On Mon, Aug 12, 2019 at 1:04 AM Martin Waschbüsch wrote: > Furthermore, the argument that it is more more work to maintain an > abandoned version is silly because it’s more work to delete a port that > to just keep it in the tree for a while longer. > >>> > >>> That last part isn't correct. The work of deleting the ports is > >>> largely automated and simple, and it will always happen eventually. > >>> The work involved is in supporting unsupported versions. Our php team > >>> is spread very thin, and they simply cannot support php versions > >>> outside of upstream development. There are no resources to backport > >>> fixes that may or may not be designed to work with older versions > >> > >> I do not understand this. At all. > >> And I sort of hope I misunderstood you, because it sounds like you think a > >> maintainer is or may be regarded as someone who can be expected to provide > >> product support of some kind? > >> I find that notion worrying to say the least. > > > > If you believe that handling updates, analyzing submitted and upstream > > patches and development, and answering a bevy of questions for every > > major update is effortless, then you drastically underestimate the > > amount of work that goes into the ports tree. > > You completely misunderstand me. > I know there is a lot of effort going into this. I disagree only in that I do > not believe there should be any expectations towards maintainers. > It is voluntary work. Spare time, etc. I am grateful for the effort people > put into this, but I strongly believe no one should act towards volunteers > with any expectations as to what they should do, how much time they spend, > etc. > > So, I find it wrong to say, as I understood you, to remove a package from the > ports tree because otherwise others people, for instance users of FreeBSD, > would have the *expectation* of receiving support for those packages. > That perception of any kind of entitlement towards volunteers is wrong, IMHO. > > And that is why I answered that part of your message because it is not (for > reasons stated above) a valid argument against having outdated software in > the ports tree. Ah! You're right, I did completely misunderstand you. You're correct that we don't provide any semblance of support for the upstream software. Absolutely, and under no circumstances should anyone have to. I'm referring to support of the port itself. Maintainership requires responding to private emails asking for help; evaluating, testing, and approving submitted patches; responding to PRs about changes or fixes or poor behaviour (90% of the time related to portmaster); responding to error reports; and so on. We do expect those things from maintainers, because those are what are required to keep the ports tree running. And we actively drop maintainership from ports where maintainers routinely ignore those responsibilities, regardless of whether they have a commit bit. As decke noted, maintainership of a small port with relatively low deployment is pretty smooth (and don't get me wrong, they're as or more important than the big packages). But a huge and complex framework like php is a massive undertaking, with a near-constant barrage of complex patches that require highly complex testing strategies, and thousands of dependent ports to worry about for every change. I suggested that it might be possible for stale languages to remain in the tree, as long as the above support wasn't required or expected. But, honestly, Franco's response mocking the offer made my desire to help him somewhere at or below zero, and has pretty much ensured that nobody else in portmgr is going to be eager to get skin in the game. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Franco Fichtner wrote on 2019/08/12 08:20: That „while“ is debatable, but it’s neither indefinitely nor immediately. The people responsible for FreeBSD ports and packages would be wise to enrich their policies with a more graceful way of dealing with legacy software, especially if it relates to more than a handful of ports in a single deprecation decision. TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading mails like these. Part of the contract in providing packages includes providing support for them. Other OSes provide packages for software that they can never support, and there are definitely consequences for that paradigm. This is doubly true for PHP, which is extremely common and for which security fixes can be vitally important. Well, you are arguing against a grace period for obsolete software which is quite pointless because the software is not bad per se. It will be eventually and it should be removed and nobody argued against that. In the case of PHP 5.6 a clear error of judgement was made based on a reasonable decision at the time. It should give enough incentive to not let this happen again so quickly and try to learn from how it negatively impacts users. +1 from me. Removing PHP 5.6 before the last version was released by upstream was very inconvenient and we end up doing 5.6.40 version ourself. Then deploy on servers which cannot be updated to 7.x at that time. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi Adam, > Am 12.08.2019 um 02:17 schrieb Adam Weinberger : > > On Sun, Aug 11, 2019 at 5:50 PM Martin Waschbüsch > wrote: >> >> Hi Adam, >> >>> Am 11.08.2019 um 23:22 schrieb Adam Weinberger : >>> >>> On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner >>> wrote: Quarterly is essentially useless if the decision is to immediately axe a deprecated release. 3 months are nothing in production environments, if you get 3 months (1,5 months mean) at all and also all other updates and security relevant bug fixes in the same quarterly that you desperately need. Yeah, we know that won’t happen so please don’t suggest it. That deprecation policy is nice and well all by itself except when it wreaks havoc over the ports infrastructure like in the case of PHP version support where numerous ports are immediately unavailable and incompatible with upgrades. Furthermore, the argument that it is more more work to maintain an abandoned version is silly because it’s more work to delete a port that to just keep it in the tree for a while longer. >>> >>> That last part isn't correct. The work of deleting the ports is >>> largely automated and simple, and it will always happen eventually. >>> The work involved is in supporting unsupported versions. Our php team >>> is spread very thin, and they simply cannot support php versions >>> outside of upstream development. There are no resources to backport >>> fixes that may or may not be designed to work with older versions >> >> I do not understand this. At all. >> And I sort of hope I misunderstood you, because it sounds like you think a >> maintainer is or may be regarded as someone who can be expected to provide >> product support of some kind? >> I find that notion worrying to say the least. > > If you believe that handling updates, analyzing submitted and upstream > patches and development, and answering a bevy of questions for every > major update is effortless, then you drastically underestimate the > amount of work that goes into the ports tree. You completely misunderstand me. I know there is a lot of effort going into this. I disagree only in that I do not believe there should be any expectations towards maintainers. It is voluntary work. Spare time, etc. I am grateful for the effort people put into this, but I strongly believe no one should act towards volunteers with any expectations as to what they should do, how much time they spend, etc. So, I find it wrong to say, as I understood you, to remove a package from the ports tree because otherwise others people, for instance users of FreeBSD, would have the *expectation* of receiving support for those packages. That perception of any kind of entitlement towards volunteers is wrong, IMHO. And that is why I answered that part of your message because it is not (for reasons stated above) a valid argument against having outdated software in the ports tree. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
* Kevin Oberman [190812 01:50]: > On Sun, Aug 11, 2019 at 4:23 PM Martin Waschbüsch > wrote: >>> Am 11.08.2019 um 23:31 schrieb Wolfgang Zenker : >>> * Martin Waschbüsch [190811 20:41]: [..] > You could also have used the quarterly branch, which keeps software till > the end of the quarter. In the case of php 5.6 it would have given you > time until March 31st, and would have included version 5.6.40 5.6.40 never made it into the main ports tree. Are you sure it was >> available in the quarterly snapshot? >>> I am sure. You can check for yourself using the svnweb interface at the >>> FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th >> Thanks, Wolfgang, for pointing that out. >> Up to now I always thought of quarterly as a static snapshot of the main >> ports tree made at a given point in time. No, quarterly gets security fixes, just no "feature updates". That's why we use it in production, so we have to handle potentially breaking changes only once a quarter. > OK. Where did 5.6.40 come from? > I just looked at the ports repo and it was NEVER committed there. The very > last commit to ports/head/lang/php56 was 5.6.39. Whil it has no impact on > me, I find it very odd to find a package that never existed in ports. That > makes it impossible for me to access the source for this package and > recreate it for any reason. My gut feeling is that this is broken and > should never happen. It was committed on the 2019Q1 branch only, because HEAD didn't have the php56 port anymore at that time. Wolfgang ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> On 12. Aug 2019, at 00:22, Adam Weinberger wrote: > >> On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner wrote: >> >> Quarterly is essentially useless if the decision is to immediately axe a >> deprecated release. 3 months are nothing in production environments, if you >> get 3 months (1,5 months mean) at all and also all other updates and >> security relevant bug fixes in the same quarterly that you desperately need. >> >> Yeah, we know that won’t happen so please don’t suggest it. >> >> That deprecation policy is nice and well all by itself except when it wreaks >> havoc over the ports infrastructure like in the case of PHP version support >> where numerous ports are immediately unavailable and incompatible with >> upgrades. >> >> Furthermore, the argument that it is more more work to maintain an abandoned >> version is silly because it’s more work to delete a port that to just keep >> it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I don’t believe this is anywhere near true for two reasons: FreeBSD ports does not add as much maintainers as it says it desperately needs so you are creating a scarce environment to base your „too much work“ argument on. The other part is having handled a ports fork myself since 2015 the work to keep a port where it is is low at its worst. >> That „while“ is debatable, but it’s neither indefinitely nor immediately. >> The people responsible for FreeBSD ports and packages would be wise to >> enrich their policies with a more graceful way of dealing with legacy >> software, especially if it relates to more than a handful of ports in a >> single deprecation decision. >> >> TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading >> mails like these. > > Part of the contract in providing packages includes providing support > for them. Other OSes provide packages for software that they can never > support, and there are definitely consequences for that paradigm. This > is doubly true for PHP, which is extremely common and for which > security fixes can be vitally important. Well, you are arguing against a grace period for obsolete software which is quite pointless because the software is not bad per se. It will be eventually and it should be removed and nobody argued against that. In the case of PHP 5.6 a clear error of judgement was made based on a reasonable decision at the time. It should give enough incentive to not let this happen again so quickly and try to learn from how it negatively impacts users. I‘m going to reiterate because nobody acknowledges the obvious: 1,5 months mean of a grace period in quarterly is productions worst enemy, not to mention when you run HEAD. > I've been thinking about this a lot lately (I used to be hardline > against it), but at this point I am not fundamentally opposed to the > idea of providing old versions of major languages and interpreters, as > long as (a) they cannot be specified by DEFAULT_VERSIONS, (b) nothing > can ever depend on them, and (c) it is clear that they are provided > without support and at your own peril. That makes no sense for PHP ports which are part of the picture here. But you probably know that. :) Cheers, Franco ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sun, Aug 11, 2019 at 5:50 PM Martin Waschbüsch wrote: > > Hi Adam, > > > Am 11.08.2019 um 23:22 schrieb Adam Weinberger : > > > > On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner > > wrote: > >> > >> Quarterly is essentially useless if the decision is to immediately axe a > >> deprecated release. 3 months are nothing in production environments, if > >> you get 3 months (1,5 months mean) at all and also all other updates and > >> security relevant bug fixes in the same quarterly that you desperately > >> need. > >> > >> Yeah, we know that won’t happen so please don’t suggest it. > >> > >> That deprecation policy is nice and well all by itself except when it > >> wreaks havoc over the ports infrastructure like in the case of PHP version > >> support where numerous ports are immediately unavailable and incompatible > >> with upgrades. > >> > >> Furthermore, the argument that it is more more work to maintain an > >> abandoned version is silly because it’s more work to delete a port that to > >> just keep it in the tree for a while longer. > > > > That last part isn't correct. The work of deleting the ports is > > largely automated and simple, and it will always happen eventually. > > The work involved is in supporting unsupported versions. Our php team > > is spread very thin, and they simply cannot support php versions > > outside of upstream development. There are no resources to backport > > fixes that may or may not be designed to work with older versions > > I do not understand this. At all. > And I sort of hope I misunderstood you, because it sounds like you think a > maintainer is or may be regarded as someone who can be expected to provide > product support of some kind? > I find that notion worrying to say the least. If you believe that handling updates, analyzing submitted and upstream patches and development, and answering a bevy of questions for every major update is effortless, then you drastically underestimate the amount of work that goes into the ports tree. Like I said in the part of my reply that you deleted, I'm open to considering another model that permits and limits ports of stale language versions. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sun, Aug 11, 2019 at 4:23 PM Martin Waschbüsch wrote: > > > Am 11.08.2019 um 23:31 schrieb Wolfgang Zenker < > wolfg...@lyxys.ka.sub.org>: > > > > * Martin Waschbüsch [190811 20:41]: > >> [..] > >>> You could also have used the quarterly branch, which keeps software > till > >>> the end of the quarter. In the case of php 5.6 it would have given you > >>> time until March 31st, and would have included version 5.6.40 > > > >> 5.6.40 never made it into the main ports tree. Are you sure it was > available in the quarterly snapshot? > > > > I am sure. You can check for yourself using the svnweb interface at the > > FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th > > Thanks, Wolfgang, for pointing that out. > > Up to now I always thought of quarterly as a static snapshot of the main > ports tree made at a given point in time. > OK. Where did 5.6.40 come from? I just looked at the ports repo and it was NEVER committed there. The very last commit to ports/head/lang/php56 was 5.6.39. Whil it has no impact on me, I find it very odd to find a package that never existed in ports. That makes it impossible for me to access the source for this package and recreate it for any reason. My gut feeling is that this is broken and should never happen. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi Adam, > Am 11.08.2019 um 23:22 schrieb Adam Weinberger : > > On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner wrote: >> >> Quarterly is essentially useless if the decision is to immediately axe a >> deprecated release. 3 months are nothing in production environments, if you >> get 3 months (1,5 months mean) at all and also all other updates and >> security relevant bug fixes in the same quarterly that you desperately need. >> >> Yeah, we know that won’t happen so please don’t suggest it. >> >> That deprecation policy is nice and well all by itself except when it wreaks >> havoc over the ports infrastructure like in the case of PHP version support >> where numerous ports are immediately unavailable and incompatible with >> upgrades. >> >> Furthermore, the argument that it is more more work to maintain an abandoned >> version is silly because it’s more work to delete a port that to just keep >> it in the tree for a while longer. > > That last part isn't correct. The work of deleting the ports is > largely automated and simple, and it will always happen eventually. > The work involved is in supporting unsupported versions. Our php team > is spread very thin, and they simply cannot support php versions > outside of upstream development. There are no resources to backport > fixes that may or may not be designed to work with older versions I do not understand this. At all. And I sort of hope I misunderstood you, because it sounds like you think a maintainer is or may be regarded as someone who can be expected to provide product support of some kind? I find that notion worrying to say the least. I cannot speak for others, but my expectation is exactly that which is found in the BSD license: That software is provided AS IS. Also, neither I, nor Franco, I suspect, are talking about backports the way e.g. Debian is doing it. (Indeed, the word backports was introduced in this discussion by someone else.) The point being made is that the end of upstream development on a piece of software should not, in and of itself, be sufficient grounds for its removal from ports. It does not cease to be useful a couple of weeks after its latest release simply because there is no one actively developing it anymore. Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 11.08.2019 um 23:31 schrieb Wolfgang Zenker : > > * Martin Waschbüsch [190811 20:41]: >> [..] >>> You could also have used the quarterly branch, which keeps software till >>> the end of the quarter. In the case of php 5.6 it would have given you >>> time until March 31st, and would have included version 5.6.40 > >> 5.6.40 never made it into the main ports tree. Are you sure it was available >> in the quarterly snapshot? > > I am sure. You can check for yourself using the svnweb interface at the > FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th Thanks, Wolfgang, for pointing that out. Up to now I always thought of quarterly as a static snapshot of the main ports tree made at a given point in time. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
* Martin Waschbüsch [190811 20:41]: > [..] >> You could also have used the quarterly branch, which keeps software till >> the end of the quarter. In the case of php 5.6 it would have given you >> time until March 31st, and would have included version 5.6.40 > 5.6.40 never made it into the main ports tree. Are you sure it was available > in the quarterly snapshot? I am sure. You can check for yourself using the svnweb interface at the FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th Wolfgang ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner wrote: > > Quarterly is essentially useless if the decision is to immediately axe a > deprecated release. 3 months are nothing in production environments, if you > get 3 months (1,5 months mean) at all and also all other updates and security > relevant bug fixes in the same quarterly that you desperately need. > > Yeah, we know that won’t happen so please don’t suggest it. > > That deprecation policy is nice and well all by itself except when it wreaks > havoc over the ports infrastructure like in the case of PHP version support > where numerous ports are immediately unavailable and incompatible with > upgrades. > > Furthermore, the argument that it is more more work to maintain an abandoned > version is silly because it’s more work to delete a port that to just keep it > in the tree for a while longer. That last part isn't correct. The work of deleting the ports is largely automated and simple, and it will always happen eventually. The work involved is in supporting unsupported versions. Our php team is spread very thin, and they simply cannot support php versions outside of upstream development. There are no resources to backport fixes that may or may not be designed to work with older versions > That „while“ is debatable, but it’s neither indefinitely nor immediately. The > people responsible for FreeBSD ports and packages would be wise to enrich > their policies with a more graceful way of dealing with legacy software, > especially if it relates to more than a handful of ports in a single > deprecation decision. > > TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading > mails like these. Part of the contract in providing packages includes providing support for them. Other OSes provide packages for software that they can never support, and there are definitely consequences for that paradigm. This is doubly true for PHP, which is extremely common and for which security fixes can be vitally important. I've been thinking about this a lot lately (I used to be hardline against it), but at this point I am not fundamentally opposed to the idea of providing old versions of major languages and interpreters, as long as (a) they cannot be specified by DEFAULT_VERSIONS, (b) nothing can ever depend on them, and (c) it is clear that they are provided without support and at your own peril. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Quarterly is essentially useless if the decision is to immediately axe a deprecated release. 3 months are nothing in production environments, if you get 3 months (1,5 months mean) at all and also all other updates and security relevant bug fixes in the same quarterly that you desperately need. Yeah, we know that won’t happen so please don’t suggest it. That deprecation policy is nice and well all by itself except when it wreaks havoc over the ports infrastructure like in the case of PHP version support where numerous ports are immediately unavailable and incompatible with upgrades. Furthermore, the argument that it is more more work to maintain an abandoned version is silly because it’s more work to delete a port that to just keep it in the tree for a while longer. That „while“ is debatable, but it’s neither indefinitely nor immediately. The people responsible for FreeBSD ports and packages would be wise to enrich their policies with a more graceful way of dealing with legacy software, especially if it relates to more than a handful of ports in a single deprecation decision. TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading mails like these. Cheers, Franco > On 11. Aug 2019, at 21:41, Martin Waschbüsch wrote: > > Hi Wolfgang, > >> Am 11.08.2019 um 01:12 schrieb Wolfgang Zenker : >> >> * Martin Waschbüsch [190811 00:47]: Am 10.08.2019 um 20:18 schrieb Patrick Powell : Umm this was just the kick in the pants that I needed to switch to PHP 7. See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' hack which I used during this update. >> >>> Thank you, Patrick, >>> that is a work-around I also came across. It helped me as well. >> >> You could also have used the quarterly branch, which keeps software till >> the end of the quarter. In the case of php 5.6 it would have given you >> time until March 31st, and would have included version 5.6.40 >> >> Wolfgang > > > 5.6.40 never made it into the main ports tree. Are you sure it was available > in the quarterly snapshot? > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi Wolfgang, > Am 11.08.2019 um 01:12 schrieb Wolfgang Zenker : > > * Martin Waschbüsch [190811 00:47]: >>> Am 10.08.2019 um 20:18 schrieb Patrick Powell : >>> >>> Umm this was just the kick in the pants that I needed to switch to PHP 7. >>> See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' >>> hack which I used during this update. > >> Thank you, Patrick, >> that is a work-around I also came across. It helped me as well. > > You could also have used the quarterly branch, which keeps software till > the end of the quarter. In the case of php 5.6 it would have given you > time until March 31st, and would have included version 5.6.40 > > Wolfgang 5.6.40 never made it into the main ports tree. Are you sure it was available in the quarterly snapshot? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
* Martin Waschbüsch [190811 00:47]: >> Am 10.08.2019 um 20:18 schrieb Patrick Powell : >> >> Umm this was just the kick in the pants that I needed to switch to PHP 7. >> See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' >> hack which I used during this update. > Thank you, Patrick, > that is a work-around I also came across. It helped me as well. You could also have used the quarterly branch, which keeps software till the end of the quarter. In the case of php 5.6 it would have given you time until March 31st, and would have included version 5.6.40 Wolfgang ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 10.08.2019 um 20:18 schrieb Patrick Powell : > > Umm this was just the kick in the pants that I needed to switch to PHP 7. > See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' > hack which I used during this update. Thank you, Patrick, that is a work-around I also came across. It helped me as well. > I must say that the update to PHP 7 was relatively painless - there is PHP6 > to PHP7 update support and lots of help/suggestions. I also found an > embarassing amount of bad PHP code during the update process, something > I should have suspected I would find. For my own projects, this is not an issue. I do try to follow the deprecation announcements for php. The issue is one where customers insist (against my explicit advice) to continue to use outdated PHP-based software that is not easily upgraded (and probably should be replaced instead of patched). > Note that the changes suggested by Mr. Glaver seem to be applicable to new > versions of the Ports tree UPDATING and .../.mk files so you can use the > latest Ports tree with the appropriate minor modifications. You can even > generate a > script to apply these updates/mods each time you run 'portsnap'. But I > digress... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 10.08.2019 um 12:53 schrieb Carmel NY : > > On Sat, 10 Aug 2019 10:17:44 +0200, Martin Waschbüsch stated: >> Would it not be better to have, say, the last two versions before >> current stable still in ports but with a huge disclaimer saying: use >> at your own risk, etc.? >> >> What do y'all think? >> >> Martin > > If I might be allowed to interpolate, I believe that continuing to > expose obsolete versions of software in the 'ports' system is a bad > Idea. It is enabling the use of software, that for one reason or > another has been superseded by a newer and possibly safer or more > mature version. Following your argument, there should no longer be a port of e.g. gcc48 in the ports tree as that, too, is no longer supported upstream. I am not saying old software should never be retired, but the end of upstream support as the *only* criteron for removal from ports tree does not sound like a good idea to me. > Usually, when a version or application is going to be removed from the > 'ports' system, it is duly noted well in advance. I would recommend > that we set a hard number, say 6 months or one year at max before said > software is removed. That should give even the most procrastinating > user ample time to render his/her system ready for that inevitability. > It they have not accomplished that with the set time frame, they > probably were never serious about doing it. > > Just my 2¢. > > -- > Carmel What happened here was: A port was updated to the last release upstream was going to publish, and *very* shortly afterwards removed from ports because support ended with said release. In the case of PHP 5.6 it was not even the last release. PHP 5.6 was removed from ports before the final upstream release. I think that a fixed time *after* the last upstream release would have been a sensible solution. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On 2019-08-10 01:17, Martin Waschbüsch wrote: Hi all, At least the last two versions of PHP, 5.6 & 7.0, were removed from ports as soon as (or even shortly before) they were no longer actively maintained upstream. I am unsure what the exact reasoning behind this was, but I do not think it is a good idea moving forward: I suppose it is true that outdated & no longer supported versions of PHP could be seen as a security risk. So far so good. However, if, for whatever reason (and I think there are legitimate ones), I still need to use a now obsolete version of PHP, having them removed from ports effectively makes it harder for me to keep everything else up-to-date. I might have to stick with an old ports revision so I cannot update other packages. If I just keep PHP as is, and update other packages, I cannot easily switch to a new version of FreeBSD itself, because I'd have to go back to an old revision of ports (hopefully working with the OS version I updated to) to compile PHP and then do other packages. Libraries / dependencies may change and break my PHP, etc. So, on top of possible security concerns for the outdated software I use, I basically get an overall less secure / stable system to boot. Now, I am not suggesting we leave every old and outdated PHP version in ports, but why remove a port just days after it received its last security update upstream? (With PHP 5.6 it was actually removed from ports before it got its last update upstream). Would it not be better to have, say, the last two versions before current stable still in ports but with a huge disclaimer saying: use at your own risk, etc.? What do y'all think? Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-port Umm this was just the kick in the pants that I needed to switch to PHP 7. See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' hack which I used during this update. I must say that the update to PHP 7 was relatively painless - there is PHP6 to PHP7 update support and lots of help/suggestions. I also found an embarassing amount of bad PHP code during the update process, something I should have suspected I would find. Note that the changes suggested by Mr. Glaver seem to be applicable to new versions of the Ports tree UPDATING and .../.mk files so you can use the latest Ports tree with the appropriate minor modifications. You can even generate a script to apply these updates/mods each time you run 'portsnap'. But I digress... -- Patrick Powell Astart Technologies papow...@astart.com1509 Hollow Ct., Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi! [...] > Would it not be better to have, say, the last two versions before > current stable still in ports but with a huge disclaimer saying: > use at your own risk, etc.? > > What do y'all think? You make the case for something other systems call backports, basically, keeping stuff in working order in the tree. Backports in other systems need someone to take up stewardship. So, either a group steps forward and takes responsibility to keep them in working order in the generic tree, e.g. by - having a mailing list, e.g. backports@, - and changing the maintainer from ports@ to backports@ - and fixing PRs as they come up Or a group provides their own pkg repo that the normal pkg-user can reference to retrieve those older packages. Both approaches sound possible, but need a non-trivial amount of investment. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sat, 10 Aug 2019 10:17:44 +0200, Martin Waschbüsch stated: >Hi all, > >At least the last two versions of PHP, 5.6 & 7.0, were removed from >ports as soon as (or even shortly before) they were no longer actively >maintained upstream. I am unsure what the exact reasoning behind this >was, but I do not think it is a good idea moving forward: > >I suppose it is true that outdated & no longer supported versions of >PHP could be seen as a security risk. So far so good. > >However, if, for whatever reason (and I think there are legitimate >ones), I still need to use a now obsolete version of PHP, having them >removed from ports effectively makes it harder for me to keep >everything else up-to-date. I might have to stick with an old ports >revision so I cannot update other packages. If I just keep PHP as is, >and update other packages, I cannot easily switch to a new version of >FreeBSD itself, because I'd have to go back to an old revision of >ports (hopefully working with the OS version I updated to) to compile >PHP and then do other packages. Libraries / dependencies may change >and break my PHP, etc. So, on top of possible security concerns for >the outdated software I use, I basically get an overall less secure / >stable system to boot. > >Now, I am not suggesting we leave every old and outdated PHP version >in ports, but why remove a port just days after it received its last >security update upstream? (With PHP 5.6 it was actually removed from >ports before it got its last update upstream). > >Would it not be better to have, say, the last two versions before >current stable still in ports but with a huge disclaimer saying: use >at your own risk, etc.? > >What do y'all think? > >Martin If I might be allowed to interpolate, I believe that continuing to expose obsolete versions of software in the 'ports' system is a bad Idea. It is enabling the use of software, that for one reason or another has been superseded by a newer and possibly safer or more mature version. Usually, when a version or application is going to be removed from the 'ports' system, it is duly noted well in advance. I would recommend that we set a hard number, say 6 months or one year at max before said software is removed. That should give even the most procrastinating user ample time to render his/her system ready for that inevitability. It they have not accomplished that with the set time frame, they probably were never serious about doing it. Just my 2¢. -- Carmel pgpGaPp09iXyS.pgp Description: OpenPGP digital signature
PHP version retirement
Hi all, At least the last two versions of PHP, 5.6 & 7.0, were removed from ports as soon as (or even shortly before) they were no longer actively maintained upstream. I am unsure what the exact reasoning behind this was, but I do not think it is a good idea moving forward: I suppose it is true that outdated & no longer supported versions of PHP could be seen as a security risk. So far so good. However, if, for whatever reason (and I think there are legitimate ones), I still need to use a now obsolete version of PHP, having them removed from ports effectively makes it harder for me to keep everything else up-to-date. I might have to stick with an old ports revision so I cannot update other packages. If I just keep PHP as is, and update other packages, I cannot easily switch to a new version of FreeBSD itself, because I'd have to go back to an old revision of ports (hopefully working with the OS version I updated to) to compile PHP and then do other packages. Libraries / dependencies may change and break my PHP, etc. So, on top of possible security concerns for the outdated software I use, I basically get an overall less secure / stable system to boot. Now, I am not suggesting we leave every old and outdated PHP version in ports, but why remove a port just days after it received its last security update upstream? (With PHP 5.6 it was actually removed from ports before it got its last update upstream). Would it not be better to have, say, the last two versions before current stable still in ports but with a huge disclaimer saying: use at your own risk, etc.? What do y'all think? Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
