Hello. John McQuah wrote in <3REIYV929TH6I.3S3P20GMVHVLB@rawtext.club>: |Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> An option would possibly be a syntax like the VERP system of SMTP |> / mailing-lists, ie, you give the optionals as part of a name, and |> the new prt-get would fail if the mentioned optionals would not be |> mentioned in the Pkgfile, but otherwise do the necessary steps. | |Following up on the example I used in my last reply, by providing |the optional dependencies as separate command-line targets (not |appendages to the main target tacked on by commas), you get all the |benefits that Steffen is proposing, but without automatically rejecting |the command as invalid if one of the additional targets is not |explicitly mentioned as an optional dependency. In the latter case, the 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. |absence of any optional dependency relationship just gives the |topological sorting algorithm more freedom in how it orders the targets. |Here's the partial output of `prt-get depinst --test --softdeps |qt6-webengine numactl pipewire` on one system (trimmed for readability): ... Yeah. That was not what i meant. I personally surely will never use a --softdeps that simply installs *none or all* optional dependencies. I mean, sure, that is then at least an official way to trigger use of the optional things, but all or nothing? For example, look at qemu-all: # Optional: alsa-lib fuse3 gnutls libaio libjpeg-turbo libpng libsdl2 libseccomp libslirp libssh liburing libxkbcommon nettle nfs-utils numactl pipewire pulseaudio python3-sphinx python3-sphinx_rtd_theme sdl2_image snappy xkeyboard-config xkeyboard-config I miss gtk somehow, hmm, but anyway, does pipewire *and* pulseaudio make any sense at all? (I only alsa.) I know i have libsdl2 (for those installers which i just cannot bend to go ncurses, and only as long as i can ssh into the machine, then of course: "none"), but none of the other sdl2 things. And surely would not want to have all that mess! ... |> Eg the core port ninja (unfortunately) has |> |> # Optional: bash-completion zsh |> |> so you could install ninja,zsh or ninja,zsh,bash-completion or or better maybe ninja/zsh. |> ninja,bash-completion,zsh, and the new prt-get would note the |> used optionals in the DB, too. | |Modifying the DB format, to indicate the precise variant of a port that |was installed, is veering too far from KISS for my tastes. Proceeding in Well there could be another file in the same dir, OpenBSD calls these things then, hm, flavours i think. flavour.db? |that direction will take you to the Nix packaging system, with thousands |of possible variants in the DB that will require more parsing logic than |our tools currently have. I preferred to retain as much of the CRUX |simplicity as possible when patching prt-get to support optional deps. Hm, maybe not if you split at the separator and sort the list. There is a main port, and its optional dependencies in sort order. |> So then prt-get update ninja would effectively mean what was used. |> And if the Pkgfile had changed in the meantime and zsh would no |> longer be Optional:, you had to uninstall first to get that |> updated. | |I have two different branches in my forked prt-get repo, one that |merges install/update/depinst so that dependencies are always resolved |and all targets in the minimal set of ports are brought up to date |(mixed-upinst), and another branch that retains the traditional |distinction among install/update/depinst. If you gave Steffen's example |`prt-get update ninja` to the mixed-upinst variant, then ninja would be |updated after all of its hard dependencies that are not the current |version, and also after all of its currently-installed soft dependencies |that are not the current version [1]. I would hope for that "prt-get quickdep" gains an option to include those (actually installed) optional dependencies. (I use that for my port-up.sh script.) |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? |Or suppose the maintainer decides to delete all zsh references from the |ninja Pkgfile. Then the mixed-upinst variant would happily leave zsh |untouched, updating only the other targets in the minimal set (ninja and |whatever else is out of date in its remaining dependency tree). And if That could then be covered by the above mechanism. Ie looking into the flavour.db first sees the "soft-dependency" of zsh, and no mention of zsh in the full DB, which then logically means zsh is a stale thing than can be removed? |no other installed port lists zsh as a hard or soft dependency, then |pkgfoster will show zsh as a possible target for removal, thanks to the |softdeps logic in 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. And pkgfoster is a total no-brainer (sorry), i need acpid and alsa-lib, #?0|kent:crux-ports.git$ pkgfoster /usr/bin/doas (Re-)checking packages for orphans... Can't open cache file: /var/lib/pkg/prt-get.cache Can't open cache file: /var/lib/pkg/prt-get.cache Package 'acpid' not found Uninstall acpid? (y/N) n Can't open cache file: /var/lib/pkg/prt-get.cache Package 'alsa-lib' not found Uninstall alsa-lib? (y/N) ^C Not that i care, i have a port-trim.sh which does it right (but relies on git-based ports to be able to deal with packages which were deliberately not updated aka are not up-to-date; but, then). |If you gave Steffen's example to the prt-get in my "master" branch, it |would do the usual thing and just update the one target passed on the |command line (ninja). Any other outdated ports in the dependency tree |would be left at their current versions. To update all ports that are |used by ninja you would have to do something convoluted like prt-get |update $(prt-get depends --softdeps ninja | awk '/^\[u/ {print $2}'). Or |even easier: prt-get sysup --softdeps (if you can afford to wait for all |the other outdated ports on your system to be rebuilt). To be honest, except for "quickdep --softdeps" this entire concept does not meet my needs. "All or nothing" for softdeps, this will not work out as such for many even, at least in a sane way. (Ie multiple graphical interfaces for qemu, multiple database backends for some server, etc etc.) I would rather see the really thoughtful "local patch mechanism" that one list member had developed, as it keeps signatures working but still allows local adjustments. |Footnote: | |[1] Thankfully both of ninja's optional dependencies still use autotools |as their build system (not ninja itself), so the check for a dependency |cycle is not triggered. If following softdeps would create a dependency |cycle, then the offending edge of the digraph is silently ignored, and |prt-get reverts to the default behavior of respecting only hard |dependencies. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)