<beerman>
I just thought about the question as in why move stuff from opt to contrib which jue asked: i came to think that opt might pave a better road to ports in contrib: e.g. llvm-family, qt6, qt5, gtk4, gtk3, librsvg.. ports that hold a certain value for the entire ports ecosystem, if you want. does that make sense? I don't see why scummvm, wireshark, gimp, firefox-bin should be opt ports, but i see the value in php, ^ruby$, smartmontools to name
<beerman>
a few
<beerman>
i feel like opt could be cleaner, a lot of ports could certainly find their home in contrib. wayland{,-protocols} should probably move to xorg if we want to keep the name of that repository, as this shouldn't really be a contrib port in the same regard
<jue>
well, we might have to redefine opt/contrib. In the past/until now opt is not a selection but a collection of ports from the opt maintainers. And contrib was its one project only coupled loosely to CRUX, e.g. the CRUX team is not per se responsible for contrib.
<jue>
btw, that's the definition by Per many years ago :)
<jue>
but, of course, we can rearrange, if we want
<beerman>
i am curious to hear what jaeger and farkuhar think about it. thanks for your thoughts on the topic jue 🙂 i am just thinking out loud
<beerman>
dunno how much it could impact the iso generation process for example, if we decide not to ship x11 by default maybe?
<beerman>
it could spare a lot of space
<beerman>
but i guess that touches a bigger topic as well: how to handle optional dependencies. its unfortunate that while doing a sysup, optional dependencies aren't considered by the logic, so when i bump vulcan stuff and bump the release of ffmpeg, it will still update ffmpeg first and vulkan stuff after that, which kinda.. makes it useless to bump the version, if not to raise awareness for the necessity to do rebuild
<beerman>
i don't really know how a solution to that would look like, though..
<beerman>
forcing a rebuild for people that don't have vulcan installed is unnecessary as well
<beerman>
s/people/deployments
<farkuhar>
beerman: your vision of opt, "ports that hold a certain value for the entire ports ecosystem", sounds very much like the design of the KISS Linux repository (121 ports total). https://kisslinux.org/#003
<farkuhar>
but the CRUX core repository already has this criterion in effect, so the role of opt has historically been more flexible, as jue pointed out.
<farkuhar>
as for the problem of optional dependencies, I don't think this reply by jw fully addresses the need for introducing new ordering relations in the digraph *before* applying topological sort: https://lists.crux.nu/pipermail/crux-devel/2008-May/003371.html
<farkuhar>
The follow-up posts in that thread immediately recognize the need for additional logic in prt-get, but as far as I can tell, such logic has not yet been added.
<farkuhar>
I have a basic idea for how to achieve (at least in my perl-based rewrite) the desired topological sort, accounting for optional dependencies. But even if I get it to work in my perl script, I'm not confident I could translate the logic into the C++ idiom of prt-get.
<jaeger>
I'm not sure that I would have any preference regarding opt vs. contrib... obviously there are historically more maintainers in contrib than opt but otherwise the main difference for me is what goes onto the ISO or not
<farkuhar>
In the 2008-May thread cited above, jue and tilman voiced two of the strongest objections to granting "Optional/Nice to have" any official recognition by prt-get. They predicted that making such metadata a mandatory field would increase the maintenance burden, as all possible combinations of installed optional dependencies would have to be tested.
<farkuhar>
There's recent precedent for opting against what beerman calls "fluid Pkgfiles" (FS#1576), in last year's curl commit "do not link against libraries that are not in core": https://crux.nu/gitweb/?p=ports/core.git;a=blobdiff;f=curl/Pkgfile;h=82ba299b7aa24af62d501c0dd1480eea02244abb;hp=bfc0d67323154a3f16430af75fc50484733cac49;hb=2d751051db7770657386ee318831ce08442cdc30;hpb=52ce4a3827f733be6f313fba31ab214605ffce15
<farkuhar>
But eager linking (or "automagic dependencies" in Gentoo parlance) is hard to anticipate if you only test your ports on a clean container. For instance: libmd and lz4 will get linked to core ports such as curl and libarchive, if present when those core ports are built.
<farkuhar>
libbsd used to infect other ports this way, but now its libraries are tucked away in a non-standard path, and a port maintainer who wants to link to libbsd will have to specify the path explicitly. That's one way to minimize the "eager linking" phenomenon; the other way is to pass configure flags that disable the unwanted linking (as in the 7 May 2022 commit to curl).
<beerman>
there is no need to make it mandatory, just if its available it should be considered, I guess
groovy2shoes has quit [Ping timeout: 260 seconds]
groovy2shoes has joined #crux-devel
<farkuhar>
I agree with beerman, port maintainers shouldn't be required to consider all possible optional dependencies. But the ones they do test, why not recognize them in our official tools, so that sysup puts the targets into (a close approximation of) the correct order?
<farkuhar>
graphite2 will be a challenging test case for any extension of the current dependency sorting to incorporate the "Optional" line. We might trigger a "cyclic dependency detected" error if we take a naive approach to implementing beerman's proposed extension, in light of this report: https://lists.crux.nu/pipermail/crux/2022-June/007203.html