[aur-general] PKGBUILD: depends vs. makedepends and namcap warning
Dear AUR list, simple question about dependencies in PKGBUILDs: Package A provides some header files and build scripts. Package B provides additional headers, and their usage only work out if A's headers are in place. Additionaly, package B can only be compiled using A's build scripts. 1) Is it correct to have package A in B's depends AND makedepends arrays? 2) Am I supposed to ignore namcap's warning 'Dependency included and not neede' because it doesn't take header dependencies into account? Thanks in advance for clarification, Lukas
On Mon, Jul 11, 2016, 10:18 Lukas Böger <dev@lboeger.de> wrote:
Dear AUR list,
simple question about dependencies in PKGBUILDs:
Package A provides some header files and build scripts. Package B provides additional headers, and their usage only work out if A's headers are in place. Additionaly, package B can only be compiled using A's build scripts.
1) Is it correct to have package A in B's depends AND makedepends arrays?
2) Am I supposed to ignore namcap's warning 'Dependency included and not neede' because it doesn't take header dependencies into account?
Thanks in advance for clarification, Lukas
1) No, depends is enough. Unlike e.g. debian, the depends you declare are implicitly part of the makedepends. 2) Yes, namcap is dumb and can only detect some dependencies, like dynamic links.
On Mon, Jul 11, 2016 at 10:18:32AM +0200, Lukas Böger wrote:
Dear AUR list,
simple question about dependencies in PKGBUILDs:
Package A provides some header files and build scripts. Package B provides additional headers, and their usage only work out if A's headers are in place. Additionaly, package B can only be compiled using A's build scripts.
1) Is it correct to have package A in B's depends AND makedepends arrays?
In general, no. If you need a dependency both at compile time and at runtime, you should put it in depends only.
2) Am I supposed to ignore namcap's warning 'Dependency included and not neede' because it doesn't take header dependencies into account?
It seems similar to this situation: https://bugs.archlinux.org/task/48277 Basically, your package B looks like a library. B should only makedepends on A, and any package depending on B should also makedepends on A. The rationale is that header files and build scripts are not needed to run a program, so they should not be installed as dependencies. They should only be installed as makedepends, for every package that needs them (even indirectly). One such example is boost: https://www.archlinux.org/packages/extra/x86_64/boost/ Baptiste
On 11.07.2016 10:38, Baptiste Jonglez wrote:
On Mon, Jul 11, 2016 at 10:18:32AM +0200, Lukas Böger wrote:
Dear AUR list,
simple question about dependencies in PKGBUILDs:
Package A provides some header files and build scripts. Package B provides additional headers, and their usage only work out if A's headers are in place. Additionaly, package B can only be compiled using A's build scripts.
1) Is it correct to have package A in B's depends AND makedepends arrays?
In general, no. If you need a dependency both at compile time and at runtime, you should put it in depends only.
2) Am I supposed to ignore namcap's warning 'Dependency included and not neede' because it doesn't take header dependencies into account?
It seems similar to this situation: https://bugs.archlinux.org/task/48277
Basically, your package B looks like a library. B should only makedepends on A, and any package depending on B should also makedepends on A.
The rationale is that header files and build scripts are not needed to run a program, so they should not be installed as dependencies. They should only be installed as makedepends, for every package that needs them (even indirectly).
One such example is boost:
https://www.archlinux.org/packages/extra/x86_64/boost/
Baptiste
Ok, thanks for the quick reply, that makes sense! And you're right, these packages are libraries. Next question: should compiler requirements be part of a PKGBUILD? In this case, when compiling with gcc, version >=4.9 is necessary. Adding it to makedepends seems like a reasonable check - on the other hand, someone who prefers clang won't have any interest in dealing with gcc versions enforced by the PKGBUILD. Lukas
On Mon, Jul 11, 2016 at 11:28:25AM +0200, Lukas Böger wrote:
Next question: should compiler requirements be part of a PKGBUILD?
No, all packages in base-devel are assumed to be already installed when using makepkg.
In this case, when compiling with gcc, version >=4.9 is necessary.
gcc is currently at 6.1.1, so version>=4.9 is already statisfied. We are a rolling release, remember :) Baptiste
Right :) After struggling with the gcc version on some older Mint system, I obviously failed to clear my mind towards rolling release^^ Now, here are my first PKGBUILDs together with a review request. Unfortunately, there are 11 of them at once, because the upstream project is subdivided into modules and they optionally depend on external libraries which also weren't in the AUR. https://gist.github.com/lubgr/d864d95b0db323da69624ac28a89efd9 The individual PKDBUILDs don't differ much, so if someone has a look at one of them, I can probably transfer hints and corrections to the other ones. Thanks in advance, Lukas On 11.07.2016 11:38, Baptiste Jonglez wrote:
On Mon, Jul 11, 2016 at 11:28:25AM +0200, Lukas Böger wrote:
Next question: should compiler requirements be part of a PKGBUILD?
No, all packages in base-devel are assumed to be already installed when using makepkg.
In this case, when compiling with gcc, version >=4.9 is necessary.
gcc is currently at 6.1.1, so version>=4.9 is already statisfied. We are a rolling release, remember :)
Baptiste
Hey, On July 11, 2016 12:25:08 PM GMT+02:00, "Lukas Böger" <dev@lboeger.de> wrote:
The individual PKDBUILDs don't differ much, so if someone has a look at one of them, I can probably transfer hints and corrections to the other ones.
DESTDIR=${pkgdir} Actually you want to put references to ${pkgdir} into quotes. It comes from outside of the PKGBUILD and may contain spaces. Cheers, Levente
participants (4)
-
Baptiste Jonglez
-
Jan Alexander Steffens
-
Levente Polyak
-
Lukas Böger