Thoughts on the EOL Policy For Ports

I was just wondering if the current policy regarding the deprecation of EOLed ports isn't causing more harm than good (for example this whole situation with python2.7). For users, we see ports disappearing from one day to the next, and even when we see the deprecation notice in time, we have the additional pressure of having to keep up with that too.

If something works for me, why should I be forced to fix it something that wasn't broke? FreeBSD is an operating system for professionals so we should probably assume that someone deciding to use an EOL software knows what they are doing. Now we need to spend time lobbying upstream to convince them to update rapidly enough, or find workarounds.

While we could instead have continued to capitalize on the initial investment made by the community to port the software. Because I feel that this policy also hurts port maintainers, as they have to spend time updating a port that is otherwise working fine.

Why not let users and port maintainers decide the pace at which they want to upgrade the various dependencies of their ports? Especially since in FreeBSD there is a separation between base and userland so the versions used in the userland do not directly affect the security of the base system (especially since production services are most of the time jailed). I feel FreeBSD should be the OS being the most accommodating for old stable software.

What are your thoughts on this? Personally I feel that the policy should be that when a port is EOLed upstream, the FreeBSD team should instead copy all the source code on FreeBSD servers to ensure that the source code remains available so that ports continue working without disruption. Working ports should be eternal, except if they use an API of the FreeBSD kernel that has been removed.
 
Python 2 needs to remain gone. As long as future versions of Python are backward compatible with Python 3, that's more than enough.

Keeping old ports that are canceled upstream or that have better simplified replacements will be more of a strain. Functionality is more important than having different variations of programs that do one function.

Something like gtk2 needs to be forked, but doing so would be incompatible for a FreeBSD way of doing things, unless dependencies of it are simplified BSD replacements that work with everything else in the BSD world.
 
Experience tells that a lot of people if not being pushed to update some component opt for postponing such updates indefinately, especially if the component in question is otherwise working for them. Also there is often not really much of a choice, even more so if the component is part of something much bigger. Take www/qt5-webengine for example, which has been almost the single source of EOL complaints in my daily status mails for god knows how long now. Choosing not to use it probably boils down to not using KDE in it's entirity, so not really an option, at least not for me.
 
Keeping old ports that are canceled upstream or that have better simplified replacements will be more of a strain. Functionality is more important than having different variations of programs that do one function.

Why would it be more of a strain? The goal is not to commit to maintaining old versions of programs, but to let maintainers and users upgrade them at their preferred pace. This would result in less strain for everybody in my opinion unless I am missing something.

Experience tells that a lot of people if not being pushed to update some component opt for postponing such updates indefinately, especially if the component in question is otherwise working for them. Also there is often not really much of a choice, even more so if the component is part of something much bigger. Take www/qt5-webengine for example, which has been almost the single source of EOL complaints in my daily status mails for god knows how long now. Choosing not to use it probably boils down to not using KDE in it's entirity, so not really an option, at least not for me.

I agree with you, but the people in questions here are professional FreeBSD users, so the question is why this urge to disrupt people's workflow. Especially since as you are pointing as well, many times there is no choice but to keep using the EOLed component.
 
I agree with you, but the people in questions here are professional FreeBSD users, so the question is why this urge to disrupt people's workflow. Especially since as you are pointing as well, many times there is no choice but to keep using the EOLed component.
As an end-user there's only so much you could do, and it's not like you were actively choosing to use an EOL software if there was a choice. Those who need to feel the pressure are the ones higher up the chain, i.e. port maintainers and upstream developers, to update the software they have claimed resposibility for in a sensible and timely fashion, as they actually do have a choice. EOL of python27 has been when? Around december? And while I admit that www/qt5-webengine is a complex piece of cra eh software, I mean come on.
 
Python is a little bit of a unique joke when it comes to backwards compatibility.

Ironically and amusingly the *only* two python programs I use actually require Python 2.x because Python 3.x interpreters are unable to run them properly.

http://moinmo.in/Python3
https://trac.edgewall.org/ticket/10083

For this I pretty much just use a Jail with an older package release (before 2.x got removed). This is really only a temporary stop gap until I can find a non-python replacement (I don't really like the python workflow, environment or technology. It is all far too temporary and short-lived).
 
I was just wondering if the current policy regarding the deprecation of EOLed ports isn't causing more harm than good (for example this whole situation with python2.7).
Python 2.7 is EOL. At this point, if an app needs legacy python, then that app is also EOL by association.

Personally I feel that the policy should be that when a port is EOLed upstream, the FreeBSD team should instead copy all the source code on FreeBSD servers to ensure that the source code remains available so that ports continue working without disruption. Working ports should be eternal, except if they use an API of the FreeBSD kernel that has been removed.
Turning ports into a museum of dead, OOD, EOL software is a security nightmare and the antithesis of progress. The FreeBSD team should not operate a life support system for abandoned projects. If that's your thing then it's on you to maintain those relics yourself.
 
I don't think a 12 years heads-up is enough. /s
Have you ever worked in the enterprise? It takes longer than 12 years to even arrange such a meeting. XD

I always thought "progress" was writing new software. Not just rewriting the same old crud over and over due to compatibility breakage ;)

Whilst I agree that it is too much for the FreeBSD team to take on, it is a flaw of the Python language. The Perl communities outright rejected Perl 6 (Raku) and Perl 7 is almost 100% compatible. A different culture.

Likewise Python 3.x style breaking changes would basically be laughed out of the language committees for C (and even C++). Even C11 is still frowned upon for portable deployments.
 
I always thought "progress" was writing new software. Not just rewriting the same old crud over and over due to compatibility breakage ;)
You'll never make it in this field. The path to success goes through:
  1. Keeping your commit count up with hundreds of crappy little changes needed to stay on some upgrade treadmill, and
  2. Writing new frameworks using more modern and of course functional languages to do almost the same thing as the old framework while taking up far more resources, and also depending on ever-shifting libraries that require lots of crappy little commits with every new version. See (1).
Yeah, the Python 3 thing is going to become one of those things that gets talked about forever. I wonder if "don't do a Python 3" will become a thing. The Python steering committee has also clearly learned the wrong lesson from it, and is now introducing breaking changes in dot releases. I'm done with that language.
 
Python 2.7 is EOL. At this point, if an app needs legacy python, then that app is also EOL by association.

This is not necessarily true, I've seen a number of projects still actively adding features, but not having the budget to rewrite their whole thing in python3.

Turning ports into a museum of dead, OOD, EOL software is a security nightmare and the antithesis of progress.

Now this is actually the point of this thread, I'd like to have other people's perspectives on why keeping old unmaintained programs in the port tree would be such a "security nightmare" and maintainance burden (the core team isn't maintaining ports - to me the maintainance burden is requiring port maintainers to continually update their port to keep up with things being declared EOLed).

People keep repeating "it's wrong because it's wrong" without really proving their point, especially considering the specific situation of FreeBSD where there is a clear separation of base and userland.

This argument would be self-explanatory with Linux, but I fail to see why it would be the case with FreeBSD. Why not just let old stuff live on in the port tree and ignore it, this is an honest question. It does not use much disk space, and it would avoid disrupting professional users understanding CVEs and what they are doing.

This would not prevent port maintainers from updating ports to address critical CVEs, and make new releases of programs available, but it would enable people needing it, and being happy with it to keep using old stacks. To me this would also mean less work for the FreeBSD team since they would no longer need to babysit the port tree.

My thinking is that FreeBSD is an operating system for professionals, and we know that enterprises often enjoy/need dwelling on old versions of stuff forever. We have the separation of base of userland, we have jails, we have a very capable package system (build options, flavors, etc...) so why not make it a unique selling proposition of FreeBSD: we don't break what works, and we trust the user to know what they are doing.

I couldn't agree more. they basically deprecated pthon2.7 overnight. I don't think a 12 years heads-up is enough. /s

Let us remember that this thread is not specifically about python, the python thing simply is a useful flashpoint to make the conversation easier and less abstract.
 
This argument would be self-explanatory with Linux, but I fail to see why it would be the case with FreeBSD. Why not just let old stuff live on in the port tree and ignore it, this is an honest question.
I highly doubt this is an honest question. Nevertheless, let's try to answer it once again: old software can't be just left alone, it might have issues with a newer compiler or use the deprecated OS functionality or depend on a whole bunch of old libraries, and, no, those can't be left alone as well because some other software requires newer versions of these libraries. All this stuff requires a lot of "non-maintenance" (according to your definition of maintenance) to keep it in working condition.

People keep repeating "it's wrong because it's wrong" without really proving their point, especially considering the specific situation of FreeBSD where there is a clear separation of base and userland.
Frankly, they don't have to prove anything to you. It's a losing proposition anyway.
 
If it's a very simple program or dependency, it can be ok. It would still need basic maintenance for security. It would have to be audited to know this, and the author would have to update that it's checked, even if no updates have been available for a long time. I haven't yet to see a program that hasn't been updated in a long time, have updates on whether it's still audited, just assumptions that it's secure.

It would have to maintained outside of FreeBSD, and port maintenance alone, I imagine is difficult as it is.
 
This is not necessarily true, I've seen a number of projects still actively adding features, but not having the budget to rewrite their whole thing in python3.
A company that can afford to write 10,000,000 lines of P2 code in the first place but can't afford to update it? Keeping P2 alive will not save this company.


People keep repeating "it's wrong because it's wrong" without really proving their point, especially considering the specific situation of FreeBSD where there is a clear separation of base and userland.
It's not a moral question, it's a question of security. Abandoned software is vulnerable and it only gets worse with time. Not to mention probable breakages as other software develops.

We have the separation of base of userland, we have jails, we have a very capable package system (build options, flavors, etc...) so why not make it a unique selling proposition of FreeBSD: we don't break what works, and we trust the user to know what they are doing.
It doesn't justify leaving EOL and abandoned software in the tree forever. Purging this cruft keeps the tree healthy and it makes life easier for admins not harder.

Let us remember that this thread is not specifically about python
Ok, but it's a great example. P2 has no development. No CVEs. No patches. It's as dead as the Monty Python parrot. Dead. Defunct. Extinct. It shuffled off this mortal coil. There's no rationale for keeping it in the tree. If you need it (or any EOL), maintain your own repo and keep it alive. But that should fall to the individual, not the group.
 
I highly doubt this is an honest question.

Frankly, they don't have to prove anything to you. It's a losing proposition anyway.

When obvious trolls come here, people happily participate and the thread becomes 3 pages long, when someone comes laying out his thinking, mindset and arguments, his honesty his cast into doubt. I have a particular issue with the second quote "Frankly, they don't have to prove anything to you. It's a losing proposition anyway", this is quite an antisocial statement to make and totally inappropriate in a discussion board. If you do not have the mood to discuss, then do not discuss. Imagine if core developers had this attitude every time someone raises a point they've already discussed.

If you are tired because this subject has been brought up before in a way addressing my concern, please feel free to send me a link to the previous discussions (not because I want you to "prove me" that the discussion exists, but because I am interested in finding answers to my questions - and I meant the same in the message you quoted). If you feel you do not need to bother, then just ignore me, but it is really inappropriate to pass your nerves on people and be so defensive.

Nevertheless, let's try to answer it once again: old software can't be just left alone, it might have issues with a newer compiler or use the deprecated OS functionality or depend on a whole bunch of old libraries, and, no, those can't be left alone as well because some other software requires newer versions of these libraries. All this stuff requires a lot of "non-maintenance" (according to your definition of maintenance) to keep it in working condition.

You make interesting points thank you, so there is 1) the issue that the builds may break which would also break the builds of all other programs depending on the old thing, and 2) the issue that separate versions of the same library may not be able to live side-by-side.

I acknowledged that builds may break on very old stuff, but I probably underestimated the extent to which a single old program or library may cascade and affect the build of other programs. The second point did not come to my mind at all.
 
I feel the EOL policy is good, as it is, there's too many people that would keep with an old unsupported software because they don't update. I am not saying people need to update right away, as you should always test changes and do a controlled roll out to the more critical hardware.

As far as Python 2.7, it should have been gone a long time ago, as in it should never had a such a long EOL span. The reason that we are having the problem now, is frankly the upstream devs were too lazy to start transitioning away. It is no way that people didn't know that 2.7 was the final version of that branch, and was on EOL. So the various packages had well more than enough time to transition it away, but waiting until the end of the time to start is their own failure straight out. Just about every other library, that they put a old branch out to EOL, everyone transitions away in a reasonable time frame; and they often don't have such a long time either.
 
Just underlining what a few already stated: TRWTF is python. Breaking changes in a programming language that seem to force complete rewrites? you're kidding me. Slight refactoring would be acceptable…

But then, leaving that aside: There's just no alternative other than finally kicking out stuff that hasn't been supported any more for a long time already. Better see all the whining now than serious and justified complaints about security incidents later.
 
If something works .....
The problem with your argument is that you assume that the goal is to accumulate working software, like accumulating wealth. But that is not what we learned from the corporations whose proprietary software we initially aspired to produce freely. Corporations like Apple know that when software reaches EOL, meaning the corporation has lost interest in selling it, that software should be removed from the market and its source code buried -- that way we avoid making the world a richer place by accumulating code and its associated know-how. For example, the GUI interface "managers" in the original MacOS were very well engineered and documented (in actual published Addison-Wesley books) so when MacOSX was invented it was important to EOL MacOS, bury it and make sure no one gets any use out of it, not even to study its source code and learn how to build gui systems. When HyperCard -- which was pretty cool and embodied very clever programming ideas -- was no longer of interest to the corporation it was withdrawn. Gone.

I think that "Free" software unconsciously follows a similar pattern. When, for example, the Gnome team gets new members with new ideas and they want to change everything, they have lost interest in "selling" the existing product, they simply declare that product obsolete, unsupported, and in fact dangerously full of bugs and security flaws, and withdraw the air from it so it dies and everyone will starting buying their new product, e.g. Gnome 2.24, 3.28, 3.38, well Gnome 40!

The ignorant (us) are assured always that it is necessary to discard the old products (as in "work product", the product of many person-years of hard work) with the warning that the old stuff is now full of bugs and security flaws and unsafe to use. But tomorrow they will say the same thing about today's software so that by process of (reverse) induction I can conclude that today's software is full of bugs and security flaws and therefore NOT superior to that which we were told to throw away.

If we would stop believing the narrative of software progress by destructive replacement we would stop writing new code to draw a window on the screen, so proud of accomplishing that which was difficult for us but which which has in fact been done probably better many times before, and talk about what needs to be done next such as universal drag-and-drop of a rich set of data types (drag-and-drop from and to the desktop, the panel, any application, of graphics, audio clips, plain text, styled text, html, ...).

As for python2 and old stuff like py-gtk2 I build my own packages so I pulled down the 2019Q3 ports tree and when I need a more retro, maybe more useful, system I'll build those ports in place of my 2021Q2 (which does have very nice KDE Plasma packages!).

-- Thank you to all porters for trying to cope with this crazy system of sometimes unnecessary and counterproductive obsolescence.
 
The primary reason packages change the major version number, is specifically to let everyone know there is some major breaking changes. As it is, pretty much all of the major libraries that are frequently use, when they have a major version/breaking change, we all end up hearing all the babies whining about it. Yet after the change is done, no one ever thinks about it until the next time. This is just the normal cycle of life, that keeps repeating every time; yet every time people start whining like the world is going to end.

Personally, I'd think it would be funny if Python EOL 3.x a couple years after 2.7 is gone; but only give 3.x less than half the EOL time frame. Considering it would be almost 15 years on 3.x line, it would be nearly time to have another major overhaul; to fix the problems in the core API foundation.
 
As it is, pretty much all of the major libraries that are frequently use, when they have a major version/breaking change, we all end up hearing all the babies whining about it.
Hah no. They end up just paying a 3rd party company a lot of money to maintain it for them and provide support. ;)

Pretty much why IBM and Oracle are still around. There is a lot of money in the maintenance business. In particular I imagine ActiveState are looking forward to the income they will now be getting from ActivePython 2.7

https://www.activestate.com/products/python/downloads/

We use the latest software because we are "enthusiasts". In the business world, things really do work differently (minus the webdev world. That seems to mainly just be enthusiasts who happen to also make money).
 
Now this is actually the point of this thread, I'd like to have other people's perspectives on why keeping old unmaintained programs in the port tree would be such a "security nightmare"...
ftp/curl had a vulnerability for several days after the ports tree was sorted out. I managed quite well but what if it was abandoned?

we don't break what works, and we trust the user to know what they are doing.
It happens more than you might think and that's expecting a lot from a lot of people IMO.
 
A company that can afford to write 10,000,000 lines of P2 code in the first place but can't afford to update it? Keeping P2 alive will not save this company.
Unfortunately I'm living in a different reality… Haven't count the lines of code, but:

Such companies keeping their customers in the dark about the fact that their expensive application, which is always provided with updates and support, has a completely outdated basement. This company might be able to keep the necessary environment running for maybe 7 more years, and then they are telling the customer: EOL of course, but hey: We have something new!

Cool, isn't it? Cashing in for many more years, and then grabbing the initial money again. Exactly such companies are successful in the long run. On the other hand, those who always fiddle around with every new version of XY spend more without getting more afterwards - just because no customer sees that effort.

And running whole outdated servers aren't a problem for many managers. As long it is running - why pay for new software? (Hint: I know the answer, but some managers are getting the first impression of it only when things stop working.)

In my case Python 2 is just needed to built some packages (and that software is NOT from companies), and I hope the upstream solves that in the near future. And that just because on date X in the future an EOL software won't compile anymore (otherwise I wouldn't bother that there's a piece of old software only on my built server - thats just "unlovely"). But till then an outdated software can be used, but the user should know about that EOL - on a public server such software might be a problem, on other machines not. So IMO the answer is: It depends.

Dropping ports just because the upstream says "no more updates" isn't useful as long this software doesn't make problems. A script f.e. isn't insecure when it hasn't been modified for the last 5 years.
 
Dropping ports just because the upstream says "no more updates" isn't useful as long this software doesn't make problems. A script f.e. isn't insecure when it hasn't been modified for the last 5 years.
Most outdated software in ports, if it doesn't have a lot of dependencies, is in fact being kept until it stops compiling or visibly breaks in runtime. (Legacy Nvidia drivers is one example.) That doesn't make a good policy, though, so this is left to committer/maintainer discretion.

Also, there is a difference between applications that are no longer maintained and something that has a new, slightly incompatible, version available. In the latter case there is an obvious solution. If upstream is unable to provide a reasonable migration path, that's on them.
 
To me it is frustrating to see duplicate work efforts. For example SeaMonkey is EOL but resurrected on the side.
It might only be temporary until upstream switches to 3.x python.
But jmos has put together a good port and then I see this post in the mailing list.
It makes me say argh. So we have 2 or 3 people building SeaMonkey and lots of overlaping work.
Our ports system should bring together coders not make them separate islands.
I have no solutions only observations. Why there is not a shim for this python deficiency is all I wonder.
I do hate losing 2500+ ports out of our system.
 
I do hate losing 2500+ ports out of our system.
It tends to be why I do not really engage with software written in Python. It sounds a little extreme but I find it has a really damaging culture of unmaintainable software and dependencies.

The same will happen at Python 4 and the cycle will begin all over again until you are stuck with a useless lemon like Gnome 3.
 
Back
Top