We have currently a clear strategy for the maintenance of 3rd party software.
We haven't, however, released any 3rd party software through our releasing system. Instead, we have been relying on separate deployments of the 3rd party software we need to be installed on customer's site.
Currently we have one example of the case where we need to release a new, previously unneeded software (sudo).
This revealed a more general problem: How do we release these kind of software? This is important issue if be (optimistically) believe that the role of 3rd party software is increasing all the time - we want to use and deliver them as a part of our own systems.
If we take the approach that we release that kind of software by our releasing system we would be forced to make modifications due to the different compilers and makefile systems originally used. This would make tracking of new versions harder. But releasing would be more convenient and we would get our own identification string inside all deliverable software.
At the same time we would also do duplicated work with versioning: The authors of, for example, GNU software, are usually very serious about handling the versioning issues. That is, for example, most of the software have a feature to tell the version number when needed.
In cases where software in question is a library the compiler and linker used must be same across all translation units - native HP-UX aCC or gcc - but not both. Note that makefile system could still be left unmodified.
Using the approach we do with Perl is another option. Unfortunately this might be too slow and heavy for us - we would be tied to external schedules. Otherwise, from our viewpoint, this is very similar as if we would be delivering all 3rd party software as own tarball - tracking of versions installed on customer's site would be done elsewhere.
A side issue in this all is this of licensing.