@sergeytolkachyov Does it have the reason described in issue #35083 , i.e. you have an uninstall SQL and that runs on update? If so, does the workaround provided in this comment #35083 (comment) work for you?

@sergeytolkachyov Does it have the reason described in issue #35083 , i.e. you have an uninstall SQL and that runs on update? If so, does the workaround provided in this comment #35083 (comment) work for you?

No, that issue does not match to mine. I haven't any sql files in library package. This issue connected with core joomla table #__extensions. there is a library XML manifest

<?xml version="1.0" encoding="UTF-8" ?>
<extension type="library" method="upgrade">
	<name>WebTolk AmoCRM library</name>
	<libraryname>Webtolk/Amocrm</libraryname>
	<version>1.0.2-alpha</version>
	<description>AmoCRM connection library</description>
	<creationDate>06/12/2022</creationDate>
	<copyright>2022 Sergey Tolkachyov</copyright>
	<license>GNU/GPL 3.0</license>
	<author>Sergey Tolkachyov</author>
	<authorEmail>info@web-tolk.ru</authorEmail>
	<authorUrl>https://web-tolk.ru</authorUrl>
	<namespace path="src">Webtolk\Amocrm</namespace>
	<files folder="libraries">
		<folder>src</folder>
		<filename>amocrm.xml</filename>
	</files>
</extension>

@richard67 Hmm, there is an installer bug only for type="library"... I'll test it. That is very strange

It's not a bug, it's a feature™

It can be removed in 5.0.

It's not a bug, it's a feature™

joomla-cms/libraries/src/Installer/Adapter/LibraryAdapter.php

Lines 47 to 57 in 485885b

	// We can upgrade, so uninstall the old one
	// We don't want to compromise this instance!
	$installer = new Installer();
	$installer->setDatabase($this->getDatabase());
	$installer->setPackageUninstall(true);
	$installer->uninstall('library', $this->currentExtensionId);
	// Clear the cached data
	$this->currentExtensionId = null;
	$this->extension = Table::getInstance('Extension', 'JTable', array('dbo' => $this->getDatabase()));

It can be removed in 5.0.

This method is no deprecated now. Why not fix it now?

Because existing extensions may rely on this behavior. In which case they do not handle the removal or renaming of library files on updates. Changing this behavior could potentially break some libraries which is why this to be done in the next major version.

@SharkyKZ What could be tougher than deleting and installing a new one instead of a real update? As far as I understand, everyone who faces this problem finds workarounds in order to restore the correct, necessary behavior. Did you read #35083 (comment) - this is just a vivid example of how developers are trying to work around the problem and achieve the desired result

Yes, I've seen that. In fact, I remember when it was supposedly fixed in #23303. I agree this behavior needs to be removed and I already explained why this should be done in 5.0. But it's not for me to decide. You can submit a PR against 4.2 if you want and hope someone merges it.

Ping