Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#43020 - filenames in PKGBUILD source array are not resolved locally.

Attached to Project: Pacman
Opened by Michael Sproul (gnusouth) - Friday, 05 December 2014, 20:36 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 07:02 GMT
Task Type Bug Report
Category makepkg
Status Assigned
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No



It seems that the build system doesn't resolve filenames correctly in the source variable. For example, the following does not work:


It gives errors like:

==> ERROR: some_file.conf was not found in the build directory and is not a URL.

The wiki lead me to believe that this was possible:

If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your PKGBUILD file is in and add the file name to this array. Any paths you add here are resolved relative to the directory where the PKGBUILD lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and makepkg will not proceed if any are missing.

Additional info:
* makepkg (pacman) 4.1.2
This task depends upon

Comment by Dave Reisner (falconindy) - Friday, 05 December 2014, 20:44 GMT
> The wiki lead me to believe that this was possible:
Pretty sure this is working as intended, and it's the wiki which needs to be fixed. Why do you need a subdirectory?
Comment by Michael Sproul (gnusouth) - Friday, 05 December 2014, 20:52 GMT
Just trying to keep things neat. I wanted to have a subdir of bundled files kept separate from temporarily downloaded junk.

This is the project:
Comment by Allan McRae (Allan) - Friday, 05 December 2014, 23:25 GMT
The wiki is wrong. Although I guess we could implement that.
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 06:58 GMT
This is basically FS#39718 except asking for all sources, not just the VCS ones.
Comment by Tomas Volf (gray_-_wolf) - Monday, 29 April 2019, 21:07 GMT
> Why do you need a subdirectory?

When patching are acquired from outside and assumed to be in one directory, having them in subdirectory can make things easier. Currently I have one extra step of creating a tarball but would be nice to be able to do it without it.
Comment by Dave Reisner (falconindy) - Monday, 29 April 2019, 21:37 GMT
> having them in subdirectory can make things easier
*how* does it make things easier?
Comment by Tomas Volf (gray_-_wolf) - Wednesday, 01 May 2019, 09:44 GMT
> *how* does it make things easier?

I could do

cp -r ~/devel/project-01/patches ./
update_checksums patches/*

instead of

cp -r ~/devel/project-01/patches ./
tar -cvJf patches.tar.xz patches
rm -rf patches
update_checksums patches.tar.xz

So it saves 2 commands.
Comment by Eli Schwartz (eschwartz) - Wednesday, 01 May 2019, 15:16 GMT
I have no idea what your personal use case here is supposed to be, but "saving 2 commands" is not a compelling argument. :/

Regardless, what is wrong with `update_checksums *.patch`?