[solved] PKGBUILD source array doesn't accept sub-directories ?

dawnofman · 2019-08-03 19:03:45

This works as expected:

source=(
   'a' \
   'b' \
   'c' \
   'https://whatever' \
   );

While this doesn't seem to work:

source=(
   'a' \
   'configuration/b' \
   'c' \
   'https://whatever' \
   );

Last edited by dawnofman (2019-08-03 19:52:53)

jasonwryan · 2019-08-03 19:06:38

man pkgbuild wrote:

Source files must either reside in the same directory as the PKGBUILD, or be a fully-qualified URL that makepkg can use to download the file.

dawnofman · 2019-08-03 19:11:45

jasonwryan wrote:

man pkgbuild wrote:
Source files must either reside in the same directory as the PKGBUILD, or be a fully-qualified URL that makepkg can use to download the file.

Yes. Of course I did check the man page. But even the "files must either reside in the same directory" seemed to imply "and everything under (if properly specified)" ... my guess; it seems an absurd limitation, doesn't it ?

Trilby · 2019-08-03 19:17:18

Saying they must reside in the same directory certainly doesn't imply to me that they could also reside in another directory.

It doesn't seem absurd to me. What possible use case could there be for subdirectories in this context?

Also note there is no need for those line continuation backslashes inside an array.

Last edited by Trilby (2019-08-03 19:17:44)

dawnofman · 2019-08-03 19:24:57

Trilby wrote:

Saying they must reside in the same directory certainly doesn't imply to me that they could also reside in another directory.

That's what I said "my guess" to begin with.

It doesn't seem absurd to me. What possible use case could there be for subdirectories in this context?

There are packages that have a LOT of configuration files (and what not). I did move every such file to a /configuration/ sub-directory (and things like that) in order to have a clean package directory with subdirectories for src and the like and not everything mixed-up in the package root directory. I like things pretty clear named and ordered. It avoids making mistakes etc.

Also note there is no need for those line continuation backslashes inside an array.

I know. Being used to typed languages and the like I write code in "automatic-mode", it is already-wired in me. And I do not like shell languages at all; this way when prototyping something, say in BASH, I can migrate it faster to some language of my choice.

jasonwryan · 2019-08-03 19:32:34

"in the same directory" is pretty definitive. If you read every man page with the same interpretative flair, you would be in for a hard time...

Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

Trilby · 2019-08-03 19:45:27

dawnofman wrote:

There are packages that have a LOT of configuration files (and what not).

For example? These probably shouldn't be uploaded to the AUR directly.

dawnofman wrote:

a clean package directory with subdirectories for src and the like and not everything mixed-up in the package root directory.

Makepkg creates the src directory and creates links there. If you mean the source code for the package, that should definitely not be uploaded to the AUR. Please give actual context or examples as your hypotheticals just aren't making any sense. I suspect there is a misunderstanding here about how the AUR works, but when everything is kept this vague nothing can actually be answered.

dawnofman · 2019-08-03 19:51:46

First and foremost thanks everybody for the (fast) replies !

Funny thing is that I just realized I can do what I was trying to do with: file:///whatever/whatever-else (if the path is given as an absolute one, that is)

jasonwryan wrote:

"in the same directory" is pretty definitive. If you read every man page with the same interpretative flair, you would be in for a hard time...

crystal-clear

Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

I know. And I humbly suggest you, that you wait a little bit more for an ongoing discussion to remind the poster of such a fact, which is OK, it is the timing that makes some noise. Anyway thanks

Trilby · 2019-08-03 21:06:28

dawnofman wrote:

Funny thing is that I just realized I can do what I was trying to do with: file:///whatever/whatever-else

Which will not work on any other computer - so I gather this is not something going to the AUR.

loqs · 2019-08-03 21:23:46

pkgname=afile
pkgver=1
pkgrel=1
arch=(any)
source=('file:///adir/afile')
package() {
true
}

makepkg
==> Making package: afile 1-1 (Sat 03 Aug 2019 21:22:13 UTC)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> ERROR: Unknown download protocol: file
    Aborting...

Edit:
See post #11

Last edited by loqs (2019-08-03 22:46:03)

dawnofman · 2019-08-03 21:28:05

Which will not work on any other computer - so I gather this is not something going to the AUR.

Of course they are not going anywhere: more or less, they are stripped-down packages, custom packages; eg: vim without a lot of crap with my custom-syntax files already in place (and without a thousand ones that I do not want to begin with) and the like, or a custom-nginx server configured with such and such module, or postgresql, etc. In every such case I rewrote the package from the ground up, keeping the original files, so everytime the original maintaner releases a new package I can check whether there are things I should take care of in my custom ones.

Anyway having the ability to specify source=('whatever/whateverelse') (ie: always relative to the package root) could be nice and practical (at least in my opinion)

Lone_Wolf · 2019-08-03 22:08:43

file:// download agent does use curl to try and download something.

makepkg does support another download agent called local: .
It's not documented outside of makepkg sourcecode, but it has been mentioned several times by pacman/makepkg contributors as the dlagent to use for source files that are stored locally.

Last edited by Lone_Wolf (2019-08-03 22:09:05)

loqs · 2019-08-03 22:29:12

Lone_wolf you have an example using local to fetch a file from another directory?

pkgname=afile
pkgver=1
pkgrel=1
arch=(any)
source=('local://adir/afile')
package() {
true
}

 makepkg
==> Making package: afile 1-1 (Sat 03 Aug 2019 22:25:56 UTC)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> ERROR: afile was not found in the build directory and is not a URL.

Edit:

pkgname=afile
pkgver=1
pkgrel=1
arch=(any)
source=('file:///adir/afile')
package() {
true
}
sha256sums=('e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855')

SRCDEST=/tmp/srcdir makepkg -f
==> Making package: afile 1-1 (Sat 03 Aug 2019 22:42:05 UTC)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found afile
==> Validating source files with sha256sums...
    afile ... Passed
==> Extracting sources...
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "afile"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: afile 1-1 (Sat 03 Aug 2019 22:42:06 UTC)
$ ls /tmp/src
afile

Even when it works makepkg is treating it as a file not as a file in a directory.

Last edited by loqs (2019-08-03 23:42:23)

Trilby · 2019-08-03 23:38:58

dawnofman wrote:

Of course they are not going anywhere...

And of course, we had no way of knowing this from the first 10 posts in this thread. Specifying your actual needs at the start of a thread would help immensely.

Lone_Wolf · 2019-08-04 12:38:17

loqs wrote:

Lone_wolf you have an example using local to fetch a file from another directory?

Nope, it seems local:: only accepts filenames and not paths.

@Dawnofman : local:: doesn't bring what you would need.

Arch Linux

#1 2019-08-03 19:03:45

[solved] PKGBUILD source array doesn't accept sub-directories ?

#2 2019-08-03 19:06:38

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#3 2019-08-03 19:11:45

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#4 2019-08-03 19:17:18

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#5 2019-08-03 19:24:57

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#6 2019-08-03 19:32:34

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#7 2019-08-03 19:45:27

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#8 2019-08-03 19:51:46

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#9 2019-08-03 21:06:28

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#10 2019-08-03 21:23:46

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#11 2019-08-03 21:28:05

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#12 2019-08-03 22:08:43

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#13 2019-08-03 22:29:12

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#14 2019-08-03 23:38:58

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

#15 2019-08-04 12:38:17

Re: [solved] PKGBUILD source array doesn't accept sub-directories ?

Board footer