Seems more or less "efficient" to me, but I'm not even sure why that's a goal. package dependencies are created once, so the focus should be less on how *fast* you can pacman -S 'the-dependency' and more on the technical merits of conveying the information that way. And I'm unconvinced that automatically generating "reasons" to install a package is the right way to go here.
Autogenerating provides for packages is a sensible manner of conveying package independent and filesystem independent information about what a repository provides in terms of capabilities rather than raw package and repository names. And unlike Appstream metadata which is awkwardly handled across various package managers, automatically generated provides can piggyback off of the already-existing provides infrastructure most package managers have.
+ for mimetype in "${mimetypes[@]}"; do + cleaned=$(echo $mimetype | xargs)
What is "cleaned", and how is the xargs program "cleaning" it?
Excess whitespace is being trimmed using xargs. " a string " will get normalized to "a string" when passed through xargs.
+ + [[ -z "$cleaned" ]] && continue
When will this be set but empty?
Trailing semicolon in desktop file will result in a blank entry in the mimetypes array, resulting in a blank can-open-mimetype() provide without this code.
Did you actually try this?
Yes, I've been using the following packages as tests for this and inspecting their metadata by hand: - vte3 (pkgconfig) - kwayland (cmake) - discover (desktop file) I know pacman can already install packages given a provides capability, so I didn't bother setting up a local test repository to confirm the fact that pacman can install these packages given their capabilities.