Add support for parallel BiT installation of OS distro and Github version?
The OP of the issue "No BiT icon on Wayland" https://github.com/bit-team/backintime/issues/1244 has raised another issue that I'd like to discuss here: When and wy shall we install into /usr/bin vs /usr/local/bin? @buhtzz already researched the differences (see https://unix.stackexchange.com/a/8658/136851) and the bottom line is: 1. /usr/bin should be used for distro package installations 2. /usr/bin/local should be used for non-distro-packaged installations Our current `make install` target installs into /usr/bin which is correct only if a package maintainer is going the package the files then. Questions: 1. Should we add more `make` targets to support different installation folders? Eg. `make install-distro` + `make install-local` 2. Shall we support parallel installations of BiT since currently we cannot install BiT without overwriting the distro installation (`make install`)? Eg. for testing a bug fix or a release candidate it would be helpful. 3. What is the impact of supporting parallel installations (2.)? I see at least - add additional desktop files with different names for the local installation - changing paths in scripts and desktop files - solving the problem that two different serviceHelper D-Bus daemons cannot work on the same service URI 4. How urgent is this?
Moin Folks, Am 18.10.2022 12:58 schrieb BiT:
1. Should we add more `make` targets to support different installation folders? Eg. `make install-distro` + `make install-local`
I don't see an advantage of that.
2. Shall we support parallel installations of BiT since currently we cannot install BiT without overwriting the distro installation (`make install`)?
If it is possible for "make" to detect other installations a warning should be displayed.
3. What is the impact of supporting parallel installations (2.)?
A real parallel installation shouldn't be supported and should be avoided by a user/developer. Testing BIT doesn't make much sense when there are two instances on the system. Possible unseen sideaffects can infer the testing results. Testing is done on an own machine or in a python virtual environment. The latter is not supported yet by BIT because it doesn't support the setuptools ("installation" or "development mode installation" via "pip"). It is on my todolist to change that. But it will affect a lot of things and is a very big modification to the repo. But it will ease up a lot of things. And in my understanding of "make" it will make "make" obsolet then.
4. How urgent is this?
Very low urgent. By the way: On my productive working machine I use BIT 1.2.1 from Debian stable for my real backups. But I also have the upstream repo there. But I don't install and run it via "make". I just call the starting script direct via "/home/user/work/backintime/common/backintime --debug" (or something like this).
Hello, Please see my answers below. On 18.10.2022 13:58, BiT wrote:
The OP of the issue "No BiT icon on Wayland"
https://github.com/bit-team/backintime/issues/1244
has raised another issue that I'd like to discuss here:
When and wy shall we install into /usr/bin vs /usr/local/bin?
@buhtzz already researched the differences (see https://unix.stackexchange.com/a/8658/136851) and the bottom line is:
1. /usr/bin should be used for distro package installations 2. /usr/bin/local should be used for non-distro-packaged installations
Our current `make install` target installs into /usr/bin which is correct only if a package maintainer is going the package the files then.
Questions:
1. Should we add more `make` targets to support different installation folders? Eg. `make install-distro` + `make install-local`
I don't think so. Normally it's handled with --prefix argument passed to configure. IMHO, we should default to /usr/local and make it clear that --prefix can be used to alter this. This allows us to adhere to tradition and knowledge formed around it.
2. Shall we support parallel installations of BiT since currently we cannot install BiT without overwriting the distro installation (`make install`)?
If we default the --prefix to /usr/local, we can both enable parallel installation, and adhere to established ways in one go. The only thing we may need to handle is presence of different configuration files for different installations, but backintime already provides a --config PATH facility for that as a runtime argument.
Eg. for testing a bug fix or a release candidate it would be helpful.
3. What is the impact of supporting parallel installations (2.)?
I see at least - add additional desktop files with different names for the local installation - changing paths in scripts and desktop files - solving the problem that two different serviceHelper D-Bus daemons cannot work on the same service URI
If we move defaults to /usr/local, I think these are automatically handled. If we really want, make can generate these files on the fly according to --prefix we provided.
4. How urgent is this?
Medium-ish if you ask me. A well playing software is high quality software. It improves perception, reduces user support load. Doing things the right way improves reputation, too. Cheers, Hakan
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
On Tue, 2022-10-18 at 14:46 +0300, Hakan Bayındır wrote:
Normally it's handled with --prefix argument passed to configure. IMHO, we should default to /usr/local and make it clear that --prefix can be used to alter this. This allows us to adhere to tradition and knowledge formed around it.
Excellent comment, I totally forgot this! "--prefix" is even implemented in "common/configure" and we needed to check if the prefix is considered everywhere (even eg. within the starter script files).
If we default the --prefix to /usr/local, we can both enable parallel installation, and adhere to established ways in one go.
Yes, we should change this and IMHO do it *after* the stabilisation release (to not confuse package maintainers and their currently working processes).
The only thing we may need to handle is presence of different configuration files for different installations, but backintime already provides a --config PATH facility for that as a runtime argument.
If you mean the config file with the backup profiles I personally use the same config for the package and (self-built) test version of BiT to compare the behavior and results. Drawback: If the config file would be updated to a new config version the old BiT version will probably no longer work. So we shouldn't change the config format anymore ;-) BiT consists of two clients (CLI and Qt GUI) and a server part ("serviceHelper.py") which is listening as system D-Bus daemon under a hard-coded URI. To support parallel installations I see more work, eg. - the daemon's configuration file(s) need to be (re)configured (injecting the prefix into paths and the D-Bus service URI) - the D-Bus service URI is hard-coded in the CLI/GUI clients and requires a refactoring into a (non-Backup-related) app.config file Summary: - Changing the installation path to usr/local is easy - Supporting parallel installations is much work => So I would change only the default inst path after the stabilization release
On 18 Oct 2022, at 22:25, BiT dev <python@altfeld-im.de> wrote:
On Tue, 2022-10-18 at 14:46 +0300, Hakan Bayındır wrote:
Normally it's handled with --prefix argument passed to configure. IMHO, we should default to /usr/local and make it clear that --prefix can be used to alter this. This allows us to adhere to tradition and knowledge formed around it.
Excellent comment, I totally forgot this!
"--prefix" is even implemented in "common/configure" and we needed to check if the prefix is considered everywhere (even eg. within the starter script files).
If we default the --prefix to /usr/local, we can both enable parallel installation, and adhere to established ways in one go.
Yes, we should change this and IMHO do it *after* the stabilisation release (to not confuse package maintainers and their currently working processes).
I concur. I did package development before, and unannounced changes, or quick changes before a distribution goes into freeze creates unnecessary stress. Being able to install BiT via packaging channels are more important for me than —prefix’s default value.
The only thing we may need to handle is presence of different configuration files for different installations, but backintime already provides a --config PATH facility for that as a runtime argument.
If you mean the config file with the backup profiles I personally use the same config for the package and (self-built) test version of BiT to compare the behavior and results. Drawback: If the config file would be updated to a new config version the old BiT version will probably no longer work. So we shouldn't change the config format anymore ;-)
BiT consists of two clients (CLI and Qt GUI) and a server part ("serviceHelper.py") which is listening as system D-Bus daemon under a hard-coded URI.
I polished over the DBus part in my mind. You’re right. Dumb me. :)
To support parallel installations I see more work, eg. - the daemon's configuration file(s) need to be (re)configured (injecting the prefix into paths and the D-Bus service URI) - the D-Bus service URI is hard-coded in the CLI/GUI clients and requires a refactoring into a (non-Backup-related) app.config file
Summary:
- Changing the installation path to usr/local is easy - Supporting parallel installations is much work
=> So I would change only the default inst path after the stabilization release
Works for me. Cheers, Hakan
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
Resending since it didn't arrive to the mailing list. Sorry if duplicate. Hello, Please see my answers below. On 18.10.2022 13:58, BiT wrote:
The OP of the issue "No BiT icon on Wayland"
https://github.com/bit-team/backintime/issues/1244
has raised another issue that I'd like to discuss here:
When and wy shall we install into /usr/bin vs /usr/local/bin?
@buhtzz already researched the differences (see https://unix.stackexchange.com/a/8658/136851) and the bottom line is:
1. /usr/bin should be used for distro package installations 2. /usr/bin/local should be used for non-distro-packaged installations
Our current `make install` target installs into /usr/bin which is correct only if a package maintainer is going the package the files then.
Questions:
1. Should we add more `make` targets to support different installation folders? Eg. `make install-distro` + `make install-local`
I don't think so. Normally it's handled with --prefix argument passed to configure. IMHO, we should default to /usr/local and make it clear that --prefix can be used to alter this. This allows us to adhere to tradition and knowledge formed around it.
2. Shall we support parallel installations of BiT since currently we cannot install BiT without overwriting the distro installation (`make install`)?
If we default the --prefix to /usr/local, we can both enable parallel installation, and adhere to established ways in one go. The only thing we may need to handle is presence of different configuration files for different installations, but backintime already provides a --config PATH facility for that as a runtime argument.
Eg. for testing a bug fix or a release candidate it would be helpful.
3. What is the impact of supporting parallel installations (2.)?
I see at least - add additional desktop files with different names for the local installation - changing paths in scripts and desktop files - solving the problem that two different serviceHelper D-Bus daemons cannot work on the same service URI
If we move defaults to /usr/local, I think these are automatically handled. If we really want, make can generate these files on the fly according to --prefix we provided.
4. How urgent is this?
Medium-ish if you ask me. A well playing software is high quality software. It improves perception, reduces user support load. Doing things the right way improves reputation, too. Cheers, Hakan
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
Hi, everyone! Everything I wanted to say has been said already ;) I think that the "configure --prefix=..." approach is the right one, and that we shouldn't change the default _for now_, because it would probably break a lot of distro packaging scripts. Supporting parallel installations will probably invite more trouble than solve any real problems. They would be mostly handy for us as developers, and I think the VM approach is cleaner for us. I haven't looked into the GH repo for a number of days, and I apologize. I'll catch up soon, I hope. Cheers! Michael On 18.10.2022 12:58, BiT wrote:
The OP of the issue "No BiT icon on Wayland"
https://github.com/bit-team/backintime/issues/1244
has raised another issue that I'd like to discuss here:
When and wy shall we install into /usr/bin vs /usr/local/bin?
@buhtzz already researched the differences (see https://unix.stackexchange.com/a/8658/136851) and the bottom line is:
1. /usr/bin should be used for distro package installations 2. /usr/bin/local should be used for non-distro-packaged installations
Our current `make install` target installs into /usr/bin which is correct only if a package maintainer is going the package the files then.
Questions:
1. Should we add more `make` targets to support different installation folders? Eg. `make install-distro` + `make install-local`
2. Shall we support parallel installations of BiT since currently we cannot install BiT without overwriting the distro installation (`make install`)?
Eg. for testing a bug fix or a release candidate it would be helpful.
3. What is the impact of supporting parallel installations (2.)?
I see at least - add additional desktop files with different names for the local installation - changing paths in scripts and desktop files - solving the problem that two different serviceHelper D-Bus daemons cannot work on the same service URI
4. How urgent is this?
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
participants (5)
-
BiT -
BiT dev
-
c.buhtz＠posteo.jp -
Hakan Bayındır -
Michael Büker