[aur-general] PKGBUILD: depends vs. makedepends and namcap warning

[Lukas Böger]

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

[Jan Alexander Steffens via aur-general]

Post by Lukas Böger
Dear AUR list,
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.

[Baptiste Jonglez]

Post by Lukas Böger
Dear AUR list,
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.

Post by Lukas Böger
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

[Lukas Böger]

Post by Baptiste Jonglez

Post by Lukas Böger
Dear AUR list,
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.

Post by Lukas Böger
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).
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

[Baptiste Jonglez]

Post by Lukas Böger
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.

Post by Lukas Böger
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

[Lukas Böger]

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

Post by Baptiste Jonglez

Post by Lukas Böger
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.

Post by Lukas Böger
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

[Levente Polyak]

Hey,

Post by Lukas Böger
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