Re: [pacman-dev] [PATCH] makepkg: Implement 'autolibprovides' option

On Tue, Oct 20, 2015 at 03:13:16AM +0300, Mohammad_AlSaleh wrote:

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 ---

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:

https://github.com/MoSal/pacman

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?

No, I don't. While it isn't so true for provides, you can easily write software which can depend on any (or many) version of a library which can only be determined after compilation. Given the nature of SRCINFO, it only makes sense to leave it ambiguous. Put differently, source code doesn't depend on sonames, compiled binaries do.

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 ?

Shouldn't that be encoded in the PKGBUILD such that you actually get a predictable build and therefore predictable dependencies/provides? What you're describing sounds like building in a dirty chroot, and/or lazy packaging. d