1. We have made changes to the 3rd party source code that we want to ship now, not when they finally let the patch into their source tree.
2. We get new updates from the latest release, patch in our stuff and we are set, quick test on the CI servers and we can ship. Yes, customers may be without the fix for a little while longer...
3. It is actually in our best interest to keep 3rd party libraries at their latest release, if we want secure software. Which is why it is part of our release documents and steps that are required to be followed before we release.
Then what you have is a fork of the library. There is no reason you can't distribute forks of the library (to either your own paths or with your own modified names) using the system package manager.
If you are expecting the person taking your patches to install them to the system, however, that's a whole 'nother ball game, and gets back to the original point: as a system administrator, I have no reason to believe your "better" versions of those libraries are going to interoperate with everything else on the system, and I am then going to have to do a bunch of work doing that isolation myself.
1. We have made changes to the 3rd party source code that we want to ship now, not when they finally let the patch into their source tree.
2. We get new updates from the latest release, patch in our stuff and we are set, quick test on the CI servers and we can ship. Yes, customers may be without the fix for a little while longer...
3. It is actually in our best interest to keep 3rd party libraries at their latest release, if we want secure software. Which is why it is part of our release documents and steps that are required to be followed before we release.