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

[Dave Reisner]

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 <CE.Mohammad.AlSaleh at 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:
> > > 
> > > 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