On Mon, Oct 19, 2015 at 07:34:10PM -0400, Dave Reisner wrote:
On Tue, Oct 20, 2015 at 02:26:39AM +0300, Mohammad_AlSaleh wrote:
On Tue, Oct 20, 2015 at 06:56:26AM +1000, Allan McRae wrote:
On 20/10/15 06:05, Mohammad Alsaleh wrote:
The option tries to find all real (no symlinks) library names in the paths a compiler/linker search for by default. And add those libraries to libprovides.
The option is disabled by default.
Signed-off-by: Mohammad Alsaleh <CE.Mohammad.AlSaleh@gmail.com> ---
Side notes:
1- I wasn't sure where to define the option. Since all options were moved to libmakepkg/tidy.
2- A side benefit of this approach is that the developer does not have to guess what to put exactly in provides. A discussion from 2.5 years ago:
https://lists.archlinux.org/pipermail/pacman-dev/2013-May/017147.html https://lists.archlinux.org/pipermail/pacman-dev/2013-May/017152.html
As I said in reply to those two years ago and previously when libprovides first appeared, I will not approve any automatic additions to the provides or depends array.
Noted.
If anyone is interested. This patch is broken as it causes the original provides to be deleted. A fixed version along with another patch that implements 'autolibdepends' are available here:
But it'll still be broken with regard to .SRCINFO generation.
Well, isn't this already broken in a sense? libdepends/libprovides are not versioned in '.SRCINFO'. And they are not of much use without their version, don't you agree? libdepends/libprovides depend on the package, not the PKGBUILD. You just can't infer them from the PKGBUILD alone. Suppose you have an upstream that might or might not build a certain library based on what dependencies are available on the system. How can you record that information in .SRCINFO ?