CB2.0 doesn't understand software versions

interfasys

Verified User
Joined
Oct 31, 2003
Messages
1,731
Location
Switzerland
Code:
# ./build versions
Latest version of DirectAdmin: 1.44.1
Installed version of DirectAdmin: 1.44.3

DirectAdmin 1.44.3 to 1.44.1 update is available.

Latest version of PCRE: 8.20
Installed version of PCRE: 8.33

PCRE 8.33 to 8.20 update is available.
 
Do you still have the problem after running ./build update? I have not seen any problems like this on any of my servers, I also run cb 2.0. However I have set files1 in custombuild. Maybe one of the DA mirrors is not updated?

Edit: If you upgraded to cb 2.0, did you remember to set "new_pcre=yes" in options.conf? If not, that should explain the one about pcre ...
 
Last edited:
We don't update libraries via CB, but the problem is not with the fact that versions.txt might be too old, but the fact that CB does not understand that 8.20 is older than 8.33. It could backfire one day.
 
CB 2.0 does understand that 8.20 is older than 8.33 on all my servers. If you do not run ./build update, then you can't expect CB to give you the correct result. You must run ./build update to have correct versions in versions.txt

No libraries is updated when you run ./build update, it only download the compressed files and update versions.txt and cb itself. Please run ./build update to fix your problem.
 
It's got nothing to do with PCRE or any library or app or version number in a config file. The script itself fails to properly compare 2 numbers
Going from 8.33 to 8.20 is not an update, it's a downgrade. CB20 does not understand that 8.33 is higher than 8.20.
 
Now you are just being difficult. There is no problems here at all. If you do not like the "wording" that is used in ./build versions, when you have old outdated versions.txt with wrong versions numbers because you refuse to update versions.txt, then I have no sympathy with that. That is not an issue. This is quibbling. Update your versions.txt to have correct result, there is nothing wrong here.
 
I've just checked the code and CB never actually tries to understand if the versions it detects are upgrades or downgrades, it will update a library every time there is a difference, assuming it's an upgrade
Code:
	if [ -e /usr/local/bin/pcre-config ]; then
		PCREV="`/usr/local/bin/pcre-config --version`"
		if [ "${VERSIONS}" = "1" ]; then
			echo "Latest version of PCRE: ${PCRE_VER}"
			echo "Installed version of PCRE: ${PCREV}"
			echo ""
		fi
		if [ [B]"${PCRE_VER}" != "${PCREV}"[/B] ]; then
			if [ "${VERSIONS}" = "0" ]; then
				echo "${boldon}Updating PCRE${boldoff}"
				[B]doPCRE;[/B]
			elif [ "${VERSIONS}" = "1" ]; then
				echo "${boldon}PCRE ${PCREV} to ${PCRE_VER} update is available.${boldoff}"
				echo ""
			fi
		fi
	fi
 
Thank you for the report. It was already discussed in http://forum.directadmin.com/showthread.php?t=38653. From what I understood you would like CustomBuild to show "Recommended version" instead of "Latest version" and "upgrade" changed to "downgrade" in case a downgrade is recommended (mainly cases when latest software is buggy), am I right?
 
The labelling doesn't really matter much, but I think it would be best if CB could be accurate about version numbers and up/downgrade path.

Case #1
OS: 3.3
CB: 3.7
Offer to upgrade to 3.7

Case #2
OS: 3.3
CB: 3.3
Let the user know that he has the latest version

Case #3
OS: 3.3
CB: 3.2 *recommended version
Recommend to downgrade only if there is a reason for it, otherwise do nothing. I figure that those downgrade cases would be quite rare. Could be if something really wrong was detected and it was recommended for all to downgrade.

Case #4
OS: 3.3.3
CB: 3.3.1
Let the user know that there is nothing to do. A downgrade should not be forced as there could be a reason for the difference or an outdated versions.txt.
As ditto has mentioned, I think it would be quite rare, after a "build update" for the installed version to be ahead of what CB offers, but there are cases where maybe someone has installed a pre-release version of something and CB should not automatically downgrade.

Also, maybe a "build update" should be performed as part of "build versions" in order to avoid some false positives?
And if I'm not mistaken, a "build update_versions" doesn't ask for any confirmation before trying to upgrade everything. Maybe it would be a good idea to get confirmation first, unless y is used?
 
"upgrade" changed to "downgrade" in case a downgrade is recommended (mainly cases when latest software is buggy), am I right?

or possibly something saying
the recommended version is lower than your version, do you want to downgrade.
that way the difference is noted and action noted too.
 
Back
Top