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 <[email protected]> > > > > > > --- > > > > > > > > > > > > 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
