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

[Mohammad_AlSaleh]

On Mon, Oct 19, 2015 at 08:18:16PM -0400, Dave Reisner wrote:
> 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.

True.

> Given the nature of SRCINFO,
> it only makes sense to leave it ambiguous.
> 

It's not ambiguous. What's included in the PKGBUILD is there. What's
not is not.

Note that I don't actually consider '.SRCINFO' generation broken. I
was/am just trying to understand your point of view.

> Put differently, source code doesn't depend on sonames, compiled
> binaries do.
> 

I thought libdepends as a feature (previously named sodepends!) was
implemented to address the runtime dependencies of the binaries!

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

Suppose the conditional build is dependant on the version of the
dependency available.

testing repo enabled -> library A built.
testing repo disabled -> library B built.

How do you record that information in '.SRCINFO' ?

> d