DesktopBSD Day 4 – Software management snags
Let’s continue with software management. I expected to wake up with a completely updated system, ready to receive further instructions in order to become a fully usable open source desktop. What I got was a system that had halted at 75%. Various updates hadn’t finished successfully. Today I spend most of my time playing with that.
Following post-install instructions
I was greeted by a window that proclaimed: â€œInstallation/upgrade of some packages failedâ€. The screen was packed with information, again kudos for that. It explained there could be four reasons for this:
- Conflicts in the package database, to be fixed by pressing the button ‘Fix package database’;
- Some installed packages might be required in a newer version than the ones installed, with the suggestion to upgrade these first;
- Binary packages for the latest version of that software might be unavailable, but might be available in a few days;
- Redistribution of certain packages in binary form is restricted. This can be solved by installing from source.
The first solution was easy enough, but there were no error messages to indicate a problem there. So, what to do next?
Tying loose ends
The first step -well, it was for me- was to repeat the upgrade procedure. I selected Upgrade all. The list of available updates consisted of quite a large set of X11 related packages and an update for the KDE desktop. Well, this one was finished quite rapidly. I noticed a long list of dependency errors and explanations why the install could not continue. What I did find strange that some packages were not installed due to being dependent on other packages in the cue that were not yet installed. It would appear that the order of the packages in the cue influences success or failure of the update/upgrade process. If so, I expect the package manager to take care of that.
Since it didn’t I decided to go through the remaining packages manually. At that point I began to realize how tedious the update/upgrade process then becomes. Select the package, click Upgrade, click No (I don’t want to read the notes), click Start. With 44 open packages it meant I needed to repeat this 44 times and only if I was able to select the right order for the packages.
I tried the first two packages: kdelibs and kdebase3. It wasn’t a really big update. Kdelibs went from version 3.5.7 to 3.5.7_3, but one never knows. The process finished without warnings of failures etc. Then I noticed the next nuisance. Once Package Manager has finished the cue it restarts itself. And again for the next cue. And again for the next cue, even if the cue is only one package.
I felt lucky because each single install seemed to go well. But then I noticed that the packages that I installed successfully (or so I thought) were still in the list of packages for which a more recent version was available. Yep, I kind of wasted a few hours on trying to update/upgrade my system and I wasn’t making any progress.
Settling for security fixes only
The security check originally mentioned nine vulnerabilities, but that list was reduced to four by the first update/upgrade run. I decided to stick to that short list and try to update the programs involved (Firefox (2 vulnerabilities), kdegraphics and cups-base). Kdegraphics finished without a problem, but didn’t disappear from the list of packages with newer available versions.
Fiddling with the settings
The information screen after the failed first upgrade/update run indicated that some packages might not be available in binary form. I went back to the settings screen in Package Manager. What solutions were available?
For one, I could select the option to select either the binary or source package, but only if the source package would be of a more recent version. The tab Advanced had three options that looked tempting:
- Always upgrade the packages required by the specified packages as well;
- Always upgrade the packages depending on the specified packages as well;
- Force processing of further packages even if prerequisite packages have failed to upgrade.
I figured that enabling all four different options at the time resembled a huge sledgehammer too much. Besides, selecting the option to use source if necessary would no doubt incur another night of updates/upgrades. I settled for the binary only option and the three other option enabled.
Well, that ran into a snag very fast. â€œStale dependency: kde-style-lipstik-2.2.2._1 –> python24-126.96.36.199 — manually run ‘pkgdb -F’ to fix (-O disallowed when -R is given).â€ Right! I clicked on Fix package database and that took care of a couple of similar problems. Another wait began.
I glued myself to the screen to check the verbose messages and one package after another was fetched and then rejected because it was the same version as the one installed. Fortunately not all of them, but more than enough to realize I would be forced to enable the option to install from source if I wanted to have the most recent versions.
At this point I settled for what I had and decided to get the software for day to day use first. But that will have to wait until tomorrow.