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

On 3/8/20 6:39 PM, Carson Black wrote:

...

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.

Examples of desktop files with this issue? I didn't find one like it on my system.

...

...

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

$ mapfile -t -d ";" mimetypes < <(grep MimeType= /usr/share/applications/qemu.desktop | cut -d '=' -f 2) $ declare -p mimetypes declare -a mimetypes=() You're wrong.

...

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.

You're not reading what I said. -- Eli Schwartz Bug Wrangler and Trusted User

On 3/8/20 6:54 PM, Carson Black wrote:

...

...

...

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.

You're not reading what I said.

Pardon, what did you mean by "Did you actually try this"?

The large quote of the patch's description immediately beforehand had me assuming that you were asking about if I had tested the patch.

I meant "look at the next few paragraphs, where I will explain why I don't think you tested this". And I explicitly ended off with "one would still NOT be able to use the automatically generated provides for packaging". But you know what, given you've said

Yes, I've been using the following packages as tests for this and inspecting their metadata by hand:

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. I guess instead of not trying "use this as a packaging dependency in PKGBUILDs", you simply didn't test it at all, which is worse than I initially thought.

So in the interest of proving that "it got successfully written to the .PKGINFO file" is not sufficient proof that the entire toolchain works, I invite you to add this repo to pacman.conf (I hacked up write_pkginfo to verbatim write the contents of any PKGBUILD-supplied function by a given name, PKGBUILDs are in this http directory): [junk] Server = https://pkgbuild.com/~eschwartz/repo/junk/ And run: $ printf '%s\n' '-`.^&=>=<: 1.0.0.0-:0 $""🤢' | sudo pacman -Syu - $ printf '%s\n' '-`.^&=>=<: 1.0.0.0-:0/ $""🤢' | sudo pacman -Syu - It's provided here, so it should work, right? : $ bsdtar -xOf test-junk2-1-1-any.pkg.tar.zst .PKGINFO | grep provides provides = -`.^&=>=<: 1.0.0.0-:0 $""🤢 $ bsdtar -xOf test-junk-1-1-any.pkg.tar.zst .PKGINFO | grep provides provides = -`.^&=>=<: 1.0.0.0-:0/ $""🤢 ... Conclusion: just because it is in the .PKGINFO, doesn't mean pacman itself can read it. You need to actually look at the changes you make, and verify the parser will accept it, and document that it works. P.S. pacman *can* read 'pkgconfig(libcurl)' provided by the same database, so that at least will be accepted by *pacman*'s parser. Even though you didn't test it. Even though makepkg won't let you depend on it in another package. -- Eli Schwartz Bug Wrangler and Trusted User

Hi Carsten,

...

...

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

That's not what actually happens; the whitespace is stripped before being written down the pipe to xargs. $ mimetype=' a string ' $ echo $mimetype | sed -n l a string$ $ It's also ‘trimming’ internal whitespace, and I don't think that matches the understood definition of trim. $ mimetype=' foo bar ' $ echo $mimetype | sed -n l foo bar$ $ Given this is bash, a built-in method may be more efficient. -- Cheers, Ralph.

On 3/8/20 9:45 PM, Allan McRae wrote:

On 9/3/20 6:04 am, Carson Black wrote:

...

The code is architected in a manner designed to make it trivial to add new provider autogenerators.

So far, there are autogenerated providers for: - pkgconfig(package) - cmake(package) - desktop files * app(desktopfilename) * can-open-mimetype(mimetype)

While these automatically generated provides can be used for packaging, this is intended more for interactive usage rather than an attempt to change how Arch packaging works.

Lets take a step back from even looking at the patch and whether it works, and focus on whether this should be a feature of makepkg/pacman at all.

Firstly, I am very against makepkg performing action that are not obvious from reading a PKGBUILD. This is why our templating system pulls the code into the PKGBUILD instead of just providing a library of functions to use. That way we can read PKGBUILDs to see the build/package commands, unlike ebuilds. It is also why libprovides & libdepends require specifying the library name, and only the version is automatically added.

Yep -- like I mentioned before, this should be opt-in via something explicitly in the PKGBUILD, libprovides is a good example of how to do that.

People have previously suggested automatically adding all dependencies on libraries to depends, and have all packages provide their libraries. This was rejected.

So, I can't see me accepting this idea either.

However, we have started splitting makepkg into smaller parts, and allowing some parts to be extendable with drop-in files. I am using that to do checking on PKGBUILDs and packages from within makepkg (https://github.com/allanmcrae/pkglint), and people have used it to add support for more build options (e.g. the following packages in the AUR: makepkg-optimize, makepkg-tidy-ect, makepkg-tidy-pdfsizeopt, makepkg-tidy-scripts-git)

One idea could be to add a method for extending a packages metadata while writing .PKGINFO. I would not accept any functions adding metadata into the pacman code base (except maybe some examples, not enabled by default), but this serves as a point for distributions to make their choices.

I kind of also need to extend this for my WIP / languishing attempts at https://git.archlinux.org/users/eschwartz/pacman.git/log/?h=autoversioned-de..., so there's definitely some interesting stuff you could do with this. That being said, changes to the metadata generation have a tendency to become thing that also need lint_pkgbuild changes, so I'm not 100% convinced thirdparty extensions can be done here *safely*. (I suppose we could just say "eh, if you modify it, it's your fault if it breaks".) -- Eli Schwartz Bug Wrangler and Trusted User

On 3/9/20 2:16 AM, Erich Eckner wrote:

Hi,

On Mon, 9 Mar 2020, Allan McRae wrote:

...

People have previously suggested automatically adding all dependencies on libraries to depends, and have all packages provide their libraries. This was rejected.

I had requested something similar once, but not exactly what you wrote (I assume, you refer to my request - if not, please ignore):

The request was to add all the provides parts, but the depends part only if one likes to (e.g. if one evaluates the stability of linking more important than an easy build path for upgrades) - but even that got rejected.

So in essence: Already *adding* the metadata is not accepted. Even if it's not intended to use it thoroughly in packages.

Adding provides=(libfoo.so) to all Arch PKGBUILDs wouldn't be a pacman-dev change. IIRC people have actually asked that makepkg automatically search through the $pkgdir and add provides=(libfoo.so=1-64) for every single installed library, whether the PKGBUILD instructs to do so or not. -- Eli Schwartz Bug Wrangler and Trusted User