First, congrats on getting GnuCash 3.8 installed! If you regularly do package installs in linux from the command line, you’ll find that nearly all of them require other packages to run. (with some exceptions for very small and simple apps.) These are referred to as ‘dependencies’ and the developer includes a file specifying a list of them, and which versions are required.
Developers test their apps using certain versions of these dependencies. Most developers either target the oldest version of the dependency they can, or otherwise target the version most likely to be default in most distros. Sometimes however, requiring a newer version cannot be avoided. Perhaps the newer version has bug fixes or features that are needed in order for the main app to work as intended. Sometimes, what appear to be bugs in the main app, are really bugs in the dependencies. Requiring a version which fixes those dependency bugs, thus also resolves a bug in the main app. In a case like GnuCash where the version of the main app is newer than the default repo, there is a good chance it relies on a dependency that is also newer than the default version. Sometimes, this fact alone is why the main app remained in the testing branch. (In this case it was a time-frame issue, GnuCash 3.8 didn’t exist at the time the Buster repo was re-designated from Testing to Stable) Note too, this can cascade. Dependencies can have dependencies, ad infinitum. If you look at the dependency section of the wiki for building GnuCash on linux, you’ll see what is required and at what versions. Anything not specifically listed there that was installed in this apt run, is a dependency of a dependency. If you see a package on your system and want to investigate why it is there, look into `apt-cache rdepends` or `apt rdepends` which will show you what is relying on that package. Check the rdepends man page sections for both `apt-cache` and `apt` as they have extra options like `--installed` which limits the command results to what is actually installed, not just what is in the repo, and `--recurse` which walks all the way back to the highest level app up the dependency chain. (so you don’t have to manually climb out of the rabbit hole one dependency level at a time) There are other options flags available to tailor the output even further. However, I don’t think these commands discern between the package being required and a specific version of it being required. (`apt` is newer than `apt-cache` and may not have as much, or might have more/different, functionality) That is, more than one app relies on `cryptsetup-initramfs:amd64` but now that version 2:2.2.2-3 is installed, those commands will still list all apps requiring it, including GnuCash, even though they might function fine with version 2:2.1.0-5+deb10u2 that was there before. The only way I know to determine that for sure is to find the dependencies of those other suspect apps and compare versions. (can also be done from the command line) As for the detailed and exact ‘why’ are those versions required of each package, you’d have to follow the development of each one, check release notes, bug reports, etc. Unless you have a serious, major breakage problem (like a video driver causing a blank display) that level of investigation is overkill but for the curious. As for potential problems with these newer versions of packages, `apt` is pretty well behaved. It will warn you if installing a newer version of something is going to break something else. It even tries to figure that out in advance and resolve the situation on its own. But when it can’t it will alert you and ask you what to do. (install the new version anyway, abort the installation, try something else) That more often happens when it can’t find the version it needs in the repo, and direct conflicts are pretty rare. Most apps don’t require a *specific* version, but rather a *minimum* version. (but the reverse does happen in rare cases) If you are ever unsure about installing something and what might get dragged in with it, use the `-s` (simulate) flag with `apt`. It will walk through the installation but not actually make any changes to your system. An important note here, is yes, this all sounds very complicated and hazardous. It really isn’t in my experience, but certainly, it doesn’t hurt to learn how to manage your system and it is good to be concerned about breaking it. As debian probably told you the first time you ran `sudo`, “With great power comes great responsibility." Regards, Adrien > On Mar 12, 2020 w11d72, at 9:48 AM, km22 <k...@gmx.com> wrote: > > As a follow up, what I did is the following to update to 3.8 on my > Debian 10 system: > > 1) Created a file /etc/apt/apt.conf with the line: APT::Default-Release > "buster"; > > 2) Ran sudo apt update. Then ran apt -t testing install gnucash > > From the /var/log/apt/history.log file these were the packages that > were installed/updated: > > Start-Date: 2020-03-10 00:14:47 > Commandline: apt -t testing install gnucash > Requested-By: ken (1000) > Install: libgwenhywfar79:amd64 (5.1.3-1, automatic), gcc-10-base:amd64 > (10-20200222-1, automatic), libhogweed5:amd64 (3.5.1+really3.5.1-2, > automatic), libgcc-s1:amd64 (10-20200222-1, automatic), libnettle7:amd64 > (3.5.1+really3.5.1-2, automatic), libffi7:amd64 (3.3-3, automatic), > libaqbanking44:amd64 (6.0.1-2, automatic), libgwengui-gtk3-0:amd64 > (5.1.3-1, automatic) > Upgrade: cryptsetup-initramfs:amd64 (2:2.1.0-5+deb10u2, 2:2.2.2-3), > libgwenhywfar-data:amd64 (4.20.0-9, 5.1.3-1), cryptsetup-run:amd64 > (2:2.1.0-5+deb10u2, 2:2.2.2-3), p11-kit-modules:amd64 (0.23.15-2, > 0.23.20-1), gnucash:amd64 (1:3.4-1+b10, 1:3.8b-1+b1), > libboost-regex1.67.0:amd64 (1.67.0-13+deb10u1, 1.67.0-17), > libaqbanking-data:amd64 (5.7.8-3, 6.0.1-2), libgnutls30:amd64 > (3.6.7-4+deb10u2, 3.6.12-2), libp11-kit0:amd64 (0.23.15-2, 0.23.20-1), > gnucash-common:amd64 (1:3.4-1, 1:3.8b-1), libtasn1-6:amd64 (4.13-3, > 4.16.0-2), libstdc++6:amd64 (8.3.0-6, 10-20200222-1), cryptsetup:amd64 > (2:2.1.0-5+deb10u2, 2:2.2.2-3), libxmlsec1:amd64 (1.2.27-2, 1.2.28-2) > End-Date: 2020-03-10 00:15:13 > > Question I have is why was it necessary for gnucash to install packages > from the testing repo for packages such as cryptsetup (various) or > gcc-10-base? Are these really necessary for gnucash? I want to > maintain a system as close to the base Debian 10 as possible so curious > to understand why these other packages were required? > > Thanks, > > Ken _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
