Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
check dependency versions and warn if they are outdated #500
Conversation
I picked the checked versions somewhat arbitrarily based on the versions shipped with Debian 9 (Stretch). The intention is to encourage users to update. If these versions are not met, then everything works as before as we only print a warning if the versions are not met. Please note: This commit introduces Perl as dependency. However, this should not be a problem as Git depends on Perl as well. Since Git is required by backup-utils, we can assume that Perl is installed on the backup host.
|
lg but my perl comprehension isn't quite up to snuff. But i'm guessing based on the regex that we're just matching against the inputted $versions, if so not bad ... |
| @@ -6,7 +6,7 @@ storage and must have network connectivity with the GitHub Enterprise Server app | ||
| ## Backup host requirements | ||
|
|
||
| Backup host software requirements are modest: Linux or other modern Unix operating | ||
| system with [bash][1], [git][2], [OpenSSH][3] 5.6 or newer, and [rsync][4] v2.6.4 or newer. | ||
| system with [bash][1], [git][2], [OpenSSH][3] 7.4 or newer, and [rsync][4] v3.1.2 or newer. |
lildude
Jun 12, 2019
Member
I think you're going to need to explicitly call out Perl now as you are directly using it.
I think you're going to need to explicitly call out Perl now as you are directly using it.
lildude
Jun 12, 2019
•
Member
Additionally, other than encouraging a user to use later versions, is there any specific reason for these versions? My fear is seeing new version requirements is going to prompt support tickets or issues asking why.
I suspect customers using RHEL (and there are quite a lot) are most likely to suddenly start seeing these version messages as they tend to be using older versions of each of these pkgs.
It's worth stating that the aim of these versions is to identify the minimum required versions.
Additionally, other than encouraging a user to use later versions, is there any specific reason for these versions? My fear is seeing new version requirements is going to prompt support tickets or issues asking why.
I suspect customers using RHEL (and there are quite a lot) are most likely to suddenly start seeing these version messages as they tend to be using older versions of each of these pkgs.
It's worth stating that the aim of these versions is to identify the minimum required versions.
larsxschneider
Jun 12, 2019
Author
Member
The main reason for all this is to ensure --ignore-missing-args is available in rsync. The flag was introduced in rsync version 3.1.0.
If the flag is not available, ghe-backup suppresses exits with code 23. That can mask potentially fatal rsync errors.
Do you think it would make sense to use RHEL 7 or something as base for the minimum versions except rsync?
The main reason for all this is to ensure --ignore-missing-args is available in rsync. The flag was introduced in rsync version 3.1.0.
If the flag is not available, ghe-backup suppresses exits with code 23. That can mask potentially fatal rsync errors.
Do you think it would make sense to use RHEL 7 or something as base for the minimum versions except rsync?
lildude
Jun 12, 2019
Member
The main reason for all this is to ensure --ignore-missing-args is available in rsync. The flag was introduced in rsync version 3.1.0.
If the flag is not available, ghe-backup suppresses exits with code 23. That can mask potentially fatal rsync errors.
🤔 I recall that change being introduced but I don't recall any scenarios of legit fatal errors this would suppress, which is why I think we went for that solution.
What fatal rsync errors is this suppressing?
If these really are fatal errors, then bumping rsync's minimum requirement makes sense. If there's no specific reason for the others, I don't think we should change their requirements.
Do you think it would make sense to use RHEL 7 or something as base for the minimum versions except rsync?
No. I think it should be the minimum versions required for the functionality we require, regardless of the OS revision. We deliberately don't make any OS recommendations because we don't and can't test against all of them.
The main reason for all this is to ensure
--ignore-missing-argsis available inrsync. The flag was introduced inrsyncversion3.1.0.If the flag is not available,
ghe-backupsuppresses exits with code 23. That can mask potentially fatalrsyncerrors.
What fatal rsync errors is this suppressing?
If these really are fatal errors, then bumping rsync's minimum requirement makes sense. If there's no specific reason for the others, I don't think we should change their requirements.
Do you think it would make sense to use RHEL 7 or something as base for the minimum versions except
rsync?
No. I think it should be the minimum versions required for the functionality we require, regardless of the OS revision. We deliberately don't make any OS recommendations because we don't and can't test against all of them.
lildude
Jun 12, 2019
Member
Additionally, if we're going to bump the minimum rsync version because of the suppression of legitimate fatal errors, I think we should make this a hard requirement and remove all the workarounds for suppressing exit code 23 too.
Additionally, if we're going to bump the minimum rsync version because of the suppression of legitimate fatal errors, I think we should make this a hard requirement and remove all the workarounds for suppressing exit code 23 too.
| check_version bash --version 4.4.12 | ||
| check_version git --version 2.11.0 | ||
| check_version rsync --version 3.1.2 | ||
| check_version ssh -V 7.4 |
lildude
Jun 12, 2019
Member
If this is not a hard requirement, we should hide these unless using verbose output.
If this is not a hard requirement, we should hide these unless using verbose output.
|
Thinking about this further, unless we have a specific requirement for these versions, I'm not sure this is something we should be doing. The versions have historically always been the minimum requirements to ensure all the functionality we require is available whilst maintaining the greatest compatibility across *nix hosts. |
I picked the checked versions somewhat arbitrarily based on the versions
shipped with Debian 9 (Stretch). The intention is to encourage users to
update. If these versions are not met, then everything works as before
as we only print a warning if the versions are not met.
Please note: This commit introduces Perl as dependency. However, this
should not be a problem as Git depends on Perl as well. Since Git is
required by backup-utils, we can assume that Perl is installed on the
backup host.