Hi Daryl, Daryl F <wyatt@prairieturtle.ca> wrote:
When qt6-base is built there is no qt6-webengine available. And when qt6-webengine is built only the qt6-base that was built independently is installed. So at build time of qt6-base there is no way to know that the optional dependency for cups in qt6-base is a hard dependency in qt6-webengine.
Thanks for explaining in detail how your docker build environment works. To the extent that it deviates from how most CRUX users will attempt to install their desktop environment, you can expect a struggle with the way our ports are currently designed. The contrib maintainers tend to write their Pkgfiles to accommodate a workflow based on `prt-get depinst $desired_toplevel_port`, not a workflow based on bootstrapping the individual dependencies "from the ground up." Hence the common idiom of conducting `prt-get isinst` or filesystem tests to determine whether the dependencies were configured appropriately.
All of the tarballs from pkgmk are retained for future use since they are each "pure" ie. having no optional or autoconfigure induced differences during their build.
Reusing a package tarball that was built in a clean docker image is already a departure from how the typical CRUX user will proceed, and therein lies your frustration with qt6-base and qt6-webengine. I sympathize with your motivation, and I can't imagine you'd be eager to adopt a workflow that disallows such reuse (opting instead to build each dependency from scratch in the clean docker image, as I naively envisioned in my first reply).
In the case of qt6-webengine it is a good test because it clearly shows what is wrong before a lengthy compile that will end in a failure. But a hard dep in qt6-base with cups would have fixed that and my automation's problem too.
The recent IRC rants against linux-pam are premised on the claim that CRUX is not living up to its name, and is now prioritizing convenience for maintainers rather than stripping away from core everything that's not essential. But at least in the case of "fluid Pkgfiles" like qt6-base, the spirit of stripping away the non-essential has been respected. You don't have to install cups to get a working build of qt6-base, just as you don't have to install linux-pam to get a usable tty on a CRUX system. Sure, opting for the hard dep in qt6-base makes things more convenient for other ports. But similar reasoning was invoked to justify putting linux-pam in core. So "fluid Pkgfiles" are arguably more aligned with the CRUX spirit of "stripping away the non-essential." Here's another solution that obviates "fluid Pkgfiles", but still accommodates the minimalist users who have no need for cups or qt6-webengine. Have qt6-webengine depend on a duplicate port qt6-base-cups, which is identical to qt6-base except that cups is a hard dependency. (It's similar to the way I configured inkscape to depend on the near-duplicate poppler-ink, to guard against build failures when poppler gets updated to a version that inkscape does not yet support. While it does clutter /usr/lib with possibly-redundant files, at least the Pkgfile does not require any branching logic to ensure a successful build--- e.g. installing a customized poppler when the wrong soversion is found.) Then you can write in prt-get.aliases the line "qt6-base-cups: qt6-base" to inform other ports that a dependency on qt6-base is satisfied if qt6-base-cups is installed. Turning to the points Steffen raised about my fork of prt-get ... Steffen Nurpmeso wrote in <20240425190115.qFKCR8uM@steffen%sdaoden.eu>:
That does not make sense, no? I do not want to install them by themselves, i only install them as optional dependencies for another thing.
Perhaps it would have been clearer if I used Steffen's example. Instead of following the SMTP / mailing list syntax (prt-get depinst ninja,zsh), just write `prt-get depinst ninja zsh`, and with "softdeps yes" in its configuration, my patched prt-get will recognize that zsh---as an optional dependency of ninja---should be moved earlier in the queue. In other words, topological sorting is performed with both types of edges in the digraph: edges connecting ports to their hard dependencies (what the original prt-get already considers), and edges connecting ports to the soft dependencies that are: - given on the command line, - already installed (in an update/sysup operation), OR - hard dependencies of other ports passed as arguments. Changing the format of the DB to indicate which "flavour" of ninja was installed is an example of "over-design". Once you allow such complexity into your DB, you might find it difficult to update ninja when the maintainer later decides to rework the dependencies. I prefer keeping the package database in its current simple format, rather than aiming for deterministic builds and completely-specificied dependencies a la NixPkgs.
I have no opinion on your --softdeps thing actually, apart from that "none or all" is surely nothing i want for approaching 100 percent of all cases.
The language "none or all" is a complete mischaracterization. You are free to inspect the Pkgfile and choose a proper subset of the optional dependencies, passing them as arguments to a `prt-get depinst` command. Using Steffen's example again: `prt-get depinst --softdeps ninja zsh` will install the optional dependency zsh, but NOT the optional dependency bash-completion (which was not given as an argument). Or to use the qemu-all example: `prt-get depinst --softdeps qemu-all libsdl2` will ensure that libsdl2 is built before qemu-all, but it will NOT automatically try to install any of the other softdeps (Steffen can retain his ALSA-only setup without worrying that pipewire and pulseaudio will be installed by this command).
Now suppose the maintainer moves zsh from "Optional" to "Depends on", and the user did not yet have zsh installed. In that case, the mixed-upinst variant is smart enough to add zsh as an install target, and build zsh before trying to update ninja.
Isn't that just the usual dependency unfolding then? What is new with this?
The new feature is only found in my mixed-upinst branch, which customizes pkgadd flags for each target (no flag if the target is not yet installed, -u if it's already installed and needs an update). Suppose your first installation of ninja did not have zsh as a hard dependency, and you never installed zsh for other reasons. But maybe the maintainer decides to make zsh a hard dependency in the next version. With the master branch of my repo, `prt-get update ninja` would refuse to inject zsh into the list of targets, because the -u flag would be invalid for the spawned pkgadd process. But the mixed-upinst branch will happily apply the -u flag only to targets already in the DB, and omit the -u flag if the target is new to the DB. There's no need to worry about the distinction between install and update, they both do the same thing in the mixed-upinst branch. As for dependency resolution (depinst versus install), that distinction has undergone a similar collapse: "install" and "update" resolve dependencies by default, but you can get the old "install" behaviour by passing the --nodeps flag. All these changes in the mixed-upinst branch were intended to make the most useful behaviour the default, so that new users don't get crucified for not reading the manual when they show up in the IRC channel and ask why they got a build failure with `prt-get install $some_port`.
prt-get listorphans.
I want to point out that these commands are totally useless as long as the hard dependency lines are as messy (and in part even by project policy) as they are. Ie listorphans gives signify and tar and such here.
I'd like to hear more discussion about the "project policy" that leads to messy "Depends on:" lines. It was my understanding that omitting runtime dependencies found in the core repo (unless they're compiled in) was intended to reduce clutter in the "Depends on" line. In his earlier message Steffen alluded to the widespread omission of openssl from the "Depends on" line (per project policy), resulting in runtime warnings from ports like postfix. If we start including even the core runtime dependencies that are not compiled in, wouldn't the "Depends on" lines get messier than they already are? I didn't patch prt-get to strip away core ports from the output of the listorphans command, because it's doing exactly what the man-page promises. Overlaying the additional knowledge of project policy that dictates how our "Depends on" lines are written is a job for an external tool. Given that a brief discussion is sometimes all it takes to change project policy (or a brief internal monologue to change the policy governing your private ports collection), a wrapper script in a port maintainer's workflow (like Steffen's port-trim.sh) is easier to adapt to new circumstances, rather than burying the consensus decision inside the subroutine for `prt-get listorphans`. My expanded man-page has a few examples that the new user can build upon, when writing such a wrapper script. https://git.crux.nu/farkuhar/prt-get/src/branch/master/doc/prt-get.8#L752 Cheers, John