jmq/prt-get
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update the notes on FS#1843

Browse Source
This commit is contained in:
John McQuah 2023-09-15 03:17:01 -04:00
parent 19a3ba19ad
commit c662852caf
1 changed files with 39 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
doc/FS1843.md
View File

@ -24,8 +24,8 @@ 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 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 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. /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 Hence there is no corresponding code in the mixed-upinst branch to solve FS#1910
would be left alone, unless forceRebuild was requested. by exiting early with an error message.
teodor's second observation is more interesting. During dependency resolution, teodor's second observation is more interesting. During dependency resolution,
the invalid arguments (ports not found in the active repos) were silently being the invalid arguments (ports not found in the active repos) were silently being
@ -33,14 +33,16 @@ 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 **all** ports passed to a ``depinst`` command are nowhere among the active
repositories, then the empty set is what gets used for executeTransaction(), repositories, then the empty set is what gets used for executeTransaction(),
with the predictable result "no package specified for install". Why did we see with the predictable result "no package specified for install". Why did we see
a different result when running ``install``? Because the calcDependencies() a different result when running ``install``? Because the calculateDependencies()
method was never called, and so executeTransaction() received the entire list method was never called, and so executeTransaction() received the entire list
of nowhere-to-be-found ports! Iterating through this list of nonexistent ports of nowhere-to-be-found ports! Iterating through this list of nonexistent ports
would populate the missingPackages list, which would then be displayed nicely would populate the missingPackages list, which would then be displayed nicely
during the post-transaction summary. during the post-transaction summary. This side-effect of toggling dependency
resolution could be observed in both the softdeps and the mixed-upinst branch,
prior to the commits of 2023-09-15.
Although we do populate a missingPackages list during calcDependencies(), the Although we do populate a missingPackages list during calculateDependencies(),
contents of this list were not being included in the post-transaction the contents of this list were not being included in the post-transaction
summary. As the code was originally conceived, executeTransaction() would get summary. As the code was originally conceived, executeTransaction() would get
a filtered list, with missing packages omitted. This side-effect of ``depinst`` a filtered list, with missing packages omitted. This side-effect of ``depinst``
violates the principle of least surprise, because users like teodor might violates the principle of least surprise, because users like teodor might
@ -48,25 +50,43 @@ justifiably expect toggling dependency resolution to generate a superset of
**their argument list** @ARGV, not just a superset of the valid ports in @ARGV. **their argument list** @ARGV, not just a superset of the valid ports in @ARGV.
To be more faithful to the principle of least surprise, the softdeps branch now 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, propagates into executeTransaction() even the ports that are not in the repos,
so that the post-transaction summary can display them. so that the post-transaction summary can display them. The mixed-upinst branch
does the same, but because it merges ``install`` and ``update``, any requested
targets that are already installed and up-to-date will appear in the
post-transaction summary under the header "Packages already installed before
this run (ignored)".
As for teodor's request to unify into one list the post-transaction summary With dependency resolution enabled, the list of "Packages already installed
of missing ports and already-up-to-date ports, I think the possible benefits before this run (ignored)" often fills up the entire height of a terminal.
for easier parsing are overstated. Some users might not want the two lists If we implemented teodor's suggestion and united the list of
mixed together, for instance when the dependency tree of a valid target ends "Packages not found" with this list --- already often big enough on its own ---
up drowning out all the ports that are not in the repos. Two separate lists then readability of the post-transaction summary would suffer.
would offer greater readability in most cases. Two separate lists would offer greater readability in most cases, both for
the human eye and for a shell script.
teodor's proposed heading for a united list, "The following ports were 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 not found/already installed:", did inspire a new way for the softdeps branch
handle FS#1910. All arguments to ``install`` and ``depinst`` will be tested 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 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 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 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 from one port to many. However, if any of the requested ports is not yet
installed, we can go ahead with initRepo() and attempt a less ambitious 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 transaction (limited to a subset of the user's argument list). The program
will reach evaluateTransaction() and display what succeeded, as well as what will reach evaluateTransaction() and display what succeeded, as well as what
was wrong with the original command. This approach will give users at was wrong with the original command.
least partial results from a malformed command, while also providing an
informative message so that a revised command can be issued later. The softdeps branch has no corresponding leniency in handling an ``update``
command, because the typical scenario for using that command is after
running ``prt-get diff``, at which point the user can be expected to know
what's on their system and to pass as arguments only the names of packages
already installed. So the early exit behaviour of my previous solution to
FS#1910 is retained for the ``update`` command. But it's easy to imagine a
user passing invalid targets to an ``install`` command, in the absence of
any cues from running ``prt-get listinst | grep -E
(package1|package2|...|packageN)``, and to handle that possibility it
makes sense to parse leniently the arguments passed to ``install``. Users
then obtain on the first try, most of what they intended, while also getting
an informative list of already-installed packages in the post-transaction report.
If they really intended to force the rebuild of those already-installed
packages, they can issue a revised command after the first command succeeds.