The computer world is becoming more complex every day, and resources to take care of FreeBSD are finite. With that combination, the grab of Murphey's Law is just a release away… And Oko's quote "most FreeBSD developers use MAC" doesn't help either.
The short version:
The FreeBSD Ports Tree should be able to handle older port releases for improved desktop stability.
The solution inspiration:
I had some issues with www/firefox, so I decided to upgrade it. I upgraded it once before, so what's the big deal, right? Well, this time, www/firefox requires a new version of multimedia/ffmpeg which fails to install due to missing doc files. Wtf? This multimedia/ffmpeg port mess also affect ports that require multimedia/ffmpeg like multimedia/vlc. How useful is my FreeBSD desktop now?
Before committing to a new port release, the port must be thoroughly tested. Perhaps that was easy in the good'ol days, but it's now wishful thinking. Systems are infinitely more complex, and they have a huge variety of peripherals. So many things to test, so little time. Bugs/issues will eventually slip through, and the end-user ends up resuming the port's test phase unknowingly.
Here's a solution to minimize breaking users' FreeBSD systems. Let older versions of a port coexist in the Ports Tree until no other port requires them. For example, you want to upgrade multimedia/ffmpeg to 2.8? Fine! Go for it! But keep 2.7 as well until multimedia/vlc, www/firefox et al., have been expressively tested using the newest 2.8 version. So, if multimedia/ffmpeg 2.8 has issues, other ports that are still based on the multimedia/ffmeg 2.7 will still be able to run. THAT'S DESIRED STABILITY FOR USERS.
In order to have several versions of the same library in the same space, the version number must be part of the file name or the file path, just like tarballs are named. Obviously, Makefile files will have to link to the specific library version that the port has been thoroughly tested with. Besides, some ports of the Ports Tree are already version specific. Why not extend this feature to all libraries? That being said, there's no need to change the entire Ports Tree to implement this solution right away. Ports can gradually be adjusted when a new version is ready to be committed in the Ports Tree. VOILA!
Needless to say that the maintainers' sanity will be spared with this solution. Possible damage will be limited to one port, and the few users that have decided to upgrade in the meantime. That's less people affected by a bad port release, less stress for the maintainers, and 'relatively' more time for them to address the issue (because everybody got offline lives). THAT'S A WIN-WIN SITUATION.
Looking forward for your input and suggestions! Hopefully, the FreeBSD Developers will find this solution appropriate.
Dominique.
The short version:
The FreeBSD Ports Tree should be able to handle older port releases for improved desktop stability.
The solution inspiration:
I had some issues with www/firefox, so I decided to upgrade it. I upgraded it once before, so what's the big deal, right? Well, this time, www/firefox requires a new version of multimedia/ffmpeg which fails to install due to missing doc files. Wtf? This multimedia/ffmpeg port mess also affect ports that require multimedia/ffmpeg like multimedia/vlc. How useful is my FreeBSD desktop now?
Before committing to a new port release, the port must be thoroughly tested. Perhaps that was easy in the good'ol days, but it's now wishful thinking. Systems are infinitely more complex, and they have a huge variety of peripherals. So many things to test, so little time. Bugs/issues will eventually slip through, and the end-user ends up resuming the port's test phase unknowingly.
Here's a solution to minimize breaking users' FreeBSD systems. Let older versions of a port coexist in the Ports Tree until no other port requires them. For example, you want to upgrade multimedia/ffmpeg to 2.8? Fine! Go for it! But keep 2.7 as well until multimedia/vlc, www/firefox et al., have been expressively tested using the newest 2.8 version. So, if multimedia/ffmpeg 2.8 has issues, other ports that are still based on the multimedia/ffmeg 2.7 will still be able to run. THAT'S DESIRED STABILITY FOR USERS.
In order to have several versions of the same library in the same space, the version number must be part of the file name or the file path, just like tarballs are named. Obviously, Makefile files will have to link to the specific library version that the port has been thoroughly tested with. Besides, some ports of the Ports Tree are already version specific. Why not extend this feature to all libraries? That being said, there's no need to change the entire Ports Tree to implement this solution right away. Ports can gradually be adjusted when a new version is ready to be committed in the Ports Tree. VOILA!
Needless to say that the maintainers' sanity will be spared with this solution. Possible damage will be limited to one port, and the few users that have decided to upgrade in the meantime. That's less people affected by a bad port release, less stress for the maintainers, and 'relatively' more time for them to address the issue (because everybody got offline lives). THAT'S A WIN-WIN SITUATION.
Looking forward for your input and suggestions! Hopefully, the FreeBSD Developers will find this solution appropriate.
Dominique.