Hi John On Fri, 26 Apr 2024, John McQuah wrote:
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.
Understood. The docker environment is in no way meant to simulate anything a CRUX user might do. It is simply meant to built a smallest footprint with the least amount of uncontrolled interaction from the system environment. I count on the use prt-get depinst.
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).
I never use these tarballs anywhere but within the docker environment. All my instances (four) of CRUX use prt-get depinst/sysup.
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.
That saves me no time. I can maintain my own port of qt6-base-cups with a hard dep for cups in it or maintain my own port of qt6-webengine. I've supported qt6-webengine before and it is a lot more work than qt6-base. Fortunately, over time, the opt port converged with mine and I was able to abandon it. On the topic of PAM: I don't care one way or the other. If it makes life for the CRUX team (bless them) easier then it should be in core. I disagree with any that say CRUX core should be the tiniest possible. AFAIK CRUX was never targeted at embedded systems. It has done very well at being a fine distro for those building servers and desktops. I don't think I've ever heard of distro that was good at that and embedded systems. Very different consumers IMO. I especially like that it has never gone to the overly complex places that Gentoo and Arch have. Arch PKGBUILD files are becoming difficult to translate to CRUX :) John, thanks for your time in this discussion. I have absolutely no complaints about what the CRUX dev team policies are. I haven't been able to provide much resource to help them and would like to see them have the least amount of work possible. I started with CRUX 2.5 in 2009 and have seen the turnover of dev personnel over the years. I don't want any of them to burn out. If they ain't having fun with CRUX they should, as a group, shrink the work as much as they see fit. Regards, Daryl