
Hello, and another fundamental basic question. ;) Please correct me if I am wrong but I realized today that that BackInTime is not one application but two; in the meaning of binaries. Looking into the git repo there are two entry points in the meaning of "if __name__ == '__main__'": /backintime/common/backintime.py /backintime/qt/app.py Nice to know. Of course I will have a closer look myself in the next weeks. But please let me ask also. Is the command-line version of backintime capable of working alone? Does it make sense to install just "backintime-cli"? I am aware that the cli version can take snapshots. But do assume it right that the cli version is not able to create a new backup job because the creating and configuration of a new backup job can be done only in the GUI, right? So can we say that backintime-cli as standalone version doesn't make sense? The background of my question is the workload of the distro maintainers who have to deal with two applications. Kind Christian

Hi Christian, No problems, just fire the questions away. ;) Yes, the command line BackInTime can work independently, without a GUI. It’s called via cron and other mechanisms to take backups in background. It actually gives some visual clues if it finds a graphical user interface (via DBus probably), but it can completely work “headless”. I sometimes use that command line to take backups without launching the user interface, personally. The GUI part of BackInTime used to have two versions (backintime-kde and backintime-gnome), GTK version dropped later, and qt version survived. The UI version is a “recommendation” for the backintime-common package in Debian, hinting further for headless operation capabilities.
But do assume it right that the cli version is not able to create a new backup job because the creating and configuration of a new backup job can be done only in the GUI, right?
You’re right. AFAIK, CLI application doesn’t have capability to build and edit configuration files and “profiles” in BackInTime parlance. Hope that’s clear enough. Please don't hesitate to contact for any questions, Cheers, Hakan

Dear Hakan, thanks for reply. Am 25.08.2022 14:59 schrieb Hakan Bayındır:
You’re right. AFAIK, CLI application doesn’t have capability to build and edit configuration files and “profiles” in BackInTime parlance.
Because of that someone could say it makes not much sense to separate that two binaries in two deb files (or any other package format). Both should be shipped out together every time, right? btw: No worry that I would change such fundamental things in the beginning of BiT maintaince. ;) I just think loud. Kind Christian

Dear Christian, Thanks for your answer. I actually gave some serious some thought to this, but I have found some convincing reasons to not to merge two packages. I know you have no intention, but it was a good food for thought: 1. Since BiT backups the config for a particular backup inside the backup folder, a headless daemon can restore this automatically. 2. Somebody might want to build another UI for it. 2a. By adding a TUI based configuration editor/manager, BiT can trivially be converted to a server backup solution. It already has a lot of nice features to support these use cases. The Travis and DBus mails are not lost on me. I just need some time for these. Cheers, Hakan On 25.08.2022 17:23, c.buhtz@posteo.jp wrote:

On 25.08.2022 13:38, c.buhtz@posteo.jp wrote:
Just yesterday, I was looking at an issue from a user who reported doing exactly that, writing the configuration by hand, referencing the manpage :) --> https://github.com/bit-team/backintime/issues/1270 A corner use case, no doubt, but it sounds really useful for headless applications. Cheers, Michael

Hi Christian, No problems, just fire the questions away. ;) Yes, the command line BackInTime can work independently, without a GUI. It’s called via cron and other mechanisms to take backups in background. It actually gives some visual clues if it finds a graphical user interface (via DBus probably), but it can completely work “headless”. I sometimes use that command line to take backups without launching the user interface, personally. The GUI part of BackInTime used to have two versions (backintime-kde and backintime-gnome), GTK version dropped later, and qt version survived. The UI version is a “recommendation” for the backintime-common package in Debian, hinting further for headless operation capabilities.
But do assume it right that the cli version is not able to create a new backup job because the creating and configuration of a new backup job can be done only in the GUI, right?
You’re right. AFAIK, CLI application doesn’t have capability to build and edit configuration files and “profiles” in BackInTime parlance. Hope that’s clear enough. Please don't hesitate to contact for any questions, Cheers, Hakan

Dear Hakan, thanks for reply. Am 25.08.2022 14:59 schrieb Hakan Bayındır:
You’re right. AFAIK, CLI application doesn’t have capability to build and edit configuration files and “profiles” in BackInTime parlance.
Because of that someone could say it makes not much sense to separate that two binaries in two deb files (or any other package format). Both should be shipped out together every time, right? btw: No worry that I would change such fundamental things in the beginning of BiT maintaince. ;) I just think loud. Kind Christian

Dear Christian, Thanks for your answer. I actually gave some serious some thought to this, but I have found some convincing reasons to not to merge two packages. I know you have no intention, but it was a good food for thought: 1. Since BiT backups the config for a particular backup inside the backup folder, a headless daemon can restore this automatically. 2. Somebody might want to build another UI for it. 2a. By adding a TUI based configuration editor/manager, BiT can trivially be converted to a server backup solution. It already has a lot of nice features to support these use cases. The Travis and DBus mails are not lost on me. I just need some time for these. Cheers, Hakan On 25.08.2022 17:23, c.buhtz@posteo.jp wrote:

On 25.08.2022 13:38, c.buhtz@posteo.jp wrote:
Just yesterday, I was looking at an issue from a user who reported doing exactly that, writing the configuration by hand, referencing the manpage :) --> https://github.com/bit-team/backintime/issues/1270 A corner use case, no doubt, but it sounds really useful for headless applications. Cheers, Michael
participants (3)
-
c.buhtz@posteo.jp
-
Hakan Bayındır
-
Michael Büker