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

[Eli Schwartz]

On 3/8/20 4:04 PM, Carson Black wrote:
> Your feedback on the code should have been addressed.
> 
>> I consider this rpm functionality to be an anti-feature, there are far
>> too many ways to depend on the exact same thing and none of it is
>> opt-in. Also, given there are very simple, intuitive tools like pkgfile
>> or pacman -F, I don't see why such complexity is needed.
> 
> I really don't consider this "too many ways to depend on the exact same
> thing." The entire point is that you're describing what capabilities you 
> want from a package instead of naming the package explicitly.

But that is in fact the exact same thing. You're describing "why" you
want the package, not "what" you want. This is the problem that I have,
because there's an infinite number of "why"s possible.

An rpm can do something like

depends=("/usr/bin/sh")

which seems pretty silly to me! Where does it end?

> And yes, I'm aware of the ability to query packages providing files,
> but looking through filenames is not as efficient a workflow as throwing a
> provides at pacman and letting it find a package that provides it.

pkgfile -q KF5whatever.cmake | pacman -S -

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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200308/9129dc88/attachment.sig>