Package Details: backintime-git 1.4.3.r54.g50c74444-1

Git Clone URL: https://aur.archlinux.org/backintime-git.git (read-only, click to copy)
Package Base: backintime-git
Description: Simple backup/snapshot system inspired by Flyback and TimeVault. Qt6 GUI version
Upstream URL: https://github.com/bit-team/backintime
Licenses: GPL-2.0-or-later
Conflicts: backintime
Provides: backintime
Submitter: willemw
Maintainer: willemw
Last Packager: willemw
Votes: 28
Popularity: 0.000000
First Submitted: 2015-10-15 03:28 (UTC)
Last Updated: 2025-05-17 07:10 (UTC)

Dependencies (16)

Required by (1)

Sources (1)

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

willemw commented on 2025-01-14 15:14 (UTC)

Very good question. Maybe from the r33.g0b3049de part of the installed package version 1.5.3.r33.g0b3049de-1 you can deduce the commit (33rd revision of g0b3049de)? But in practice I think Build Date is used (pacman -Qi backintime-git) and the URL in sources= (in the PKGBUILD file) to determine the git branch.

buhtz commented on 2025-01-14 14:26 (UTC)

That is a burden for upstream maintainers. Imagine users telling me they use Back In Time from Arch. How should I know which version that is.

willemw commented on 2025-01-14 08:51 (UTC)

For devel packages (*-git, etc.) the real version number is only on the user's machine. The version number on the AUR site is not relevant (except for a forced version bump by the maintainer when needed.)

Does the Arch AUR package tools to update existing installations to the latest upstream commit?

Yes. But each tool may do it differently. Paru and yay use git ls-remote to compare the latest local and remote commit.

buhtz commented on 2025-01-14 08:36 (UTC)

whenever you install or reinstall a -git package with such a default URL, it will install the latest commit on the default branch.

Then why is the version number of the package "1.4.3.r54.g50c74444-1" but upstream is far beyond that version?

Does the Arch AUR package tools to update existing installations to the latest upstream commit?

willemw commented on 2024-09-29 16:52 (UTC)

In the PKGBUILD file, the main source url in source= becomes git+https://github.com/bit-team/backintime.git after variable expansion, which results in a git clone https://github.com/bit-team/backintime.git call.

So yes, whenever you install or reinstall a -git package with such a default URL, it will install the latest commit on the default branch.

https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources explains how to change the URL to select another git repo, another branch or select a commit. It can be changed to install, for example, a specific pull request.

buhtz commented on 2024-09-29 14:47 (UTC)

Hi, is it your PKGBUILD pinned to a specific commit in the upstreams default branch or does it really always use the latest commit by its own?

buhtz commented on 2024-07-07 07:44 (UTC)

Hello willemw, my apologize. The script is really called via the make system. This gives me a headache. It is time we migrate to modern Python Packaging Standards to prevent workarounds like this.

willemw commented on 2024-07-06 16:54 (UTC)

@buhtz: please have a look at the build script (see the "View PKGBUILD" link on this page). It basically just follows the install instructions: "configure; make; make install". It's not calling any backintime scripts. I think I'll wait for the https://github.com/bit-team/backintime/pull/1782 fix.

buhtz commented on 2024-07-06 14:55 (UTC) (edited on 2024-07-06 15:08 (UTC) by buhtz)

The error is related to your packaging not to upstream. The folder "debian" was removed from upstream because it is not relevant and is especially not relevant to Arch.

EDIT: Ah... You use "updateversion.sh". That is prohibited for distro package maintainers. Just don't use it. It is a helper script for upstream maintainers only.

EDIT2: Please see this PR for a fix https://github.com/bit-team/backintime/pull/1782 . But again, I don't see a reason why you would use that script on your side.

willemw commented on 2024-07-06 12:54 (UTC)

@buhtz: *-git packages update themselves when you, the user, (re)install the package(s).

1 2 3 4 5 6 .. 9 Next › Last »