[pacman-dev] [PATCH] Provides generation for files (a.k.a. rpm fileattrs for makepkg)

Carson Black uhhadd at gmail.com
Sun Mar 8 22:39:11 UTC 2020

> 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.

More information about the pacman-dev mailing list