I would expect that as you have moved the libraries to a non standard lcoation

I would expect that as you have moved the libraries to a non standard lcoation

brianteeman - you're a genius

Agreed with Brian. What you did is not an officially supported feature. Thus I don't expect it to work through updates and even regular functions of the core may be broken.
Closing as expected behavior.

JPATH_LIBRARIES in custom defined.php

Bakual - is not an officially supported feature

??? That's so the news!...

It's one of those edge cases where you can probably make parts of it work but other parts just won't. Update unpacking is one of those places it doesn't work. I wouldn't be so quick to call this "unsupported", otherwise the override ability would have never been placed in the boot up sequence, but "fixing" it is something that is going to be more effort than it's worth as long as the Joomla core is updated by the Joomla core as a files extension.

mbabker - Hello friend

Just need in com_installer, or where update process worked, include defined.php and use them with update process.

Obviously, that need an elegant solution, but for this needs brains, work which many do not have the desire.

All easier to close the issue with the formulation: "unsupported feature".

Give me info where update process worked ("com_installer, etc..."), maybe I something and sometime invent for this issue...

It isn't that. Joomla is updated as a file extension type (so using JInstallerAdapterFile for processing). A file extension seriously just dumps out the package contents to the directory specified in the extension manifest; it does NOT use or support path constants. Nor should it. Because Joomla is updated using its own extension installation library, it is limited to what it can do based on the adapter's featureset. Inherently, there are two options to improve this:

• A custom extension adapter which has this "extra" logic
• Updating Joomla with a proper standalone code base (meaning updates are truly decoupled from the core platform to the extent practical; at a minimum this would include the package extraction and filesystem cleanup functions, in theory this could also include the database migrations by having the standalone code boot up the application framework to hook into that portion of the API)

...I known, that manifest files "it does NOT use or support path constants"...

This similar situation described in my post "The problem with the rights to JComments, when the user is in multiple groups"

Where author JComments answer on problem: "Yes, completely rewrite the entire system of storage and processing of rights" - HORROR!

I decided not to waste time arguing and solve the problem yourself... The problem was solved with five lines of code without "completely rewrite the entire system of storage and processing of rights"! The patch I have not opened to the author, because they are ignorant treated me - after next updating Jcomments, I just apply of my patch.

In connection with such an ignorant attitude of the author of many CMS and plugins for them, to the problems encountered, even possible it will be easier to take Composer, ADOdb, PHPMailer, Twig, Buzz, Guzzle, Imagine, TCPDF, Minify, HybridAuth (etc lib), write custom router and make own CMF/CMS - possible this a better option than wasting time on proving bug? :)

Nevertheless, in which files exactly goes processing update process? Where placed this "own extension installation library" and how their name?