prt-get/doc/FS1843.md

Flyspray 1843 notes

Was: Re: Please make the output of prt-get --test more common

teodor observed that prt-get --test gives two different styles of output. The output style was found to be affected by the number of packages requested on the command line (one versus many), and by whether dependency resolution was toggled (install versus depinst).

In the case when one package was requested for installation, an early check of /var/lib/pkg/db for the existence of a previous installation would alert the user to the malformed command. No such check of /var/lib/pkg/db was being performed for multiple packages passed on the command line (FS#1910), and so the program continued all the way through executeTransaction() and evaluateResult(), which produced the more verbose output that teodor noted.

A similar discrepancy could be observed when requesting an update of one package that was not previously installed, versus an update of multiple packages among which there are some not yet installed. You would have seen a terse warning in the first case, and a more verbose output in the second case.

The softdeps branch in this code base is now more consistent in performing the scan of /var/lib/pkg/db, no matter how many packages are passed as argument. But the mixed-upinst branch collapses the distinction between install and update, always bringing up to date all the ports passed as argument (and their dependencies, unless --nodeps is given), so it can postpone the scan of /var/lib/pkg/db until the step of customizing pkgadd flags for each target. Ports exhibiting no version differences between the repos and /var/lib/pkg/db would be left alone, unless forceRebuild was requested.

teodor's second observation is more interesting. During dependency resolution, the invalid arguments (ports not found in the active repos) were silently being dropped, rather than being kept in memory for a post-transaction report. If all ports passed to a depinst command are nowhere among the active repositories, then the empty set is what gets used for executeTransaction(), with the predictable result "no package specified for install". Why did we see a different result when running install? Because the calcDependencies() method was never called, and so executeTransaction() received the entire list of nowhere-to-be-found ports! Iterating through this list of nonexistent ports would populate the missingPackages list, which would then be displayed nicely during the post-transaction summary.

Although we do populate a missingPackages list during calcDependencies(), the contents of this list were not being included in the post-transaction summary. As the code was originally conceived, executeTransaction() would get a filtered list, with missing packages omitted. This side-effect of depinst violates the principle of least surprise, because users like teodor might justifiably expect toggling dependency resolution to generate a superset of their argument list @, not just a superset of the valid ports in @. To be more faithful to the principle of least surprise, the softdeps branch now propagates into executeTransaction() even the ports that are not in the repos, so that the post-transaction summary can display them.

As for teodor's request to unify into one list the post-transaction summary of missing ports and already-up-to-date ports, I think the possible benefits for easier parsing are overstated. Some users might not want the two lists mixed together, for instance when the dependency tree of a valid target ends up drowning out all the ports that are not in the repos. Two separate lists would offer greater readability in most cases.

teodor's proposed heading for a united list, "The following ports were not found/already installed:", suggests a new way for the softdeps branch to handle FS#1910. All arguments to install and depinst will be tested against /var/lib/pkg/db to ensure that they're not already installed, and if all the tests fail then the user is immediately alerted to the malformed command. This preliminary check is simply jw's original design, but extended from one port to many. Then, if any of the requested ports is not yet installed, we can go ahead with initRepo() and attempt a less ambitious transaction (limited to a subset of the user's argument list). The program will reach evaluateTransaction() and display what succeeded, as well as what was wrong with the original command. This approach will give users at least partial results from a malformed command, while also providing an informative message so that a revised command can be issued later.