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

[Dave Reisner]

On Oct 19, 2015 8:42 PM, "Mohammad_AlSaleh" <ce.mohammad.alsaleh at gmail.com>
wrote:
>
> 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.

It absolutely is ambiguous without the version.

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

Again, you don't. You name the soname without there version.