Hi Daryl, Daryl F <wyatt@prairieturtle.ca> wrote:
softdeps in the docker environment would pollute the new footprints with things that the end consumer of one of my ports may not be using in their system.
I might not have the clearest picture of how your docker setup works, so please correct me if this description is wrong: when generating the footprint of a new port (take qutebrowser as an example), you load a docker image that consists of a core-only environment, and run `prt-get depinst qutebrowser`. Along the way, it might generate footprints for some dependencies that aren't yet installed (those that didn't have a footprint already), but the only footprint you keep for the purposes of publishing the qutebrowser port is the qutebrowser footprint. In other words, the footprints of dependencies are NOT updated, even if pkgmk reports NEW files for some of them. If that's how your docker setup works, I don't expect pollution of the resulting footprint by toggling the --softdeps switch. As I wrote, it still calculates the _minimal_ set of dependencies needed to install the requested targets, using hard dependencies just as the original prt-get does. The only effect of --softdeps is in the topological sorting: in the event that there happen to be optional dependency relationships among the resulting minimal set of targets, prt-get will be smart enough to recognize them and move the optional dependencies earlier in the queue (e.g., cups before qt6-base, resulting in NEW files in the qt6-base footprint, but nothing NEW in qt6-webengine which is the actual target requested for installation). This feature is similar to what Steffen described as "VERP system of SMTP / mailing lists" (but the optional dependencies appear as separate arguments, not adornments of the main target tacked on with commas). By way of illustration, here's the output of `prt-get depinst --test --softdeps qt6-webengine` on a working system (not core-only, but at least it lacks cups and qt6 stuff): *** prt-get: test mode -- Packages installed minizip libb2 abseil-cpp snappy re2 python3-six python3-webencodings python3-html5lib cups xorg-xcb-util-cursor qt6-base qt6-shadertools qt6-serialport qt6-declarative qt6-positioning qt6-tools qt6-websockets qt6-webchannel qt6-webengine -- installed packages with README files: /usr/ports/opt/cups prt-get: installed successfully Note that although qt6-webengine lists numactl and pipewire as optional dependencies, and the test system did not have these ports installed, the prt-get command did not add them to the set of install targets. If you want a maximal port, you have to do more work to get it (see link at the end of this post). Topological sorting is also modified in a sysup operation: my patched prt-get has the logic to update an optional dependency before the port that optionally depends on it (e.g., vulkan-loader before mesa, which is not the order you're guaranteed to get with the original prt-get). In fact, it was the optional dependencies of mesa that originally prompted my work on this fork.
I recall the discussion about optional dependencies. I was neither for or against it. Some might find it useful to automatically include them but I just review the ports and manually install an optionals I like.
I hope I've given a better explanation of what "softdeps yes" in the configuration file (or --softdeps on the command line) actually does. To reiterate: it does NOT automatically include as install targets all the ports in the "Optional:" field, it only applies a smarter sorting algorithm to the ports that are passed as arguments (and their hard dependencies). The expanded man-page demonstrates an unwieldy command if you want to build a "maximally interdependent" package, but this is not the default behavior when you set "softdeps yes". https://git.crux.nu/farkuhar/prt-get/src/branch/master/doc/prt-get.8#L719 -- John