[pacman-dev] [PATCH] makepkg: Implement 'autolibprovides' option
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@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 etc/makepkg.conf.in | 23 ++++++++++++----------- scripts/makepkg.sh.in | 22 ++++++++++++++++++++++ 2 files changed, 34 insertions(+), 11 deletions(-) diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index 71ec624..da6e7ad 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -74,18 +74,19 @@ BUILDENV=(!distcc color !ccache check !sign) # Default: OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !upx !optipng !debug) # A negated option will do the opposite of the comments below. # -#-- strip: Strip symbols from binaries/libraries -#-- docs: Save doc directories specified by DOC_DIRS -#-- libtool: Leave libtool (.la) files in packages +#-- strip: Strip symbols from binaries/libraries +#-- docs: Save doc directories specified by DOC_DIRS +#-- libtool: Leave libtool (.la) files in packages #-- staticlibs: Leave static library (.a) files in packages -#-- emptydirs: Leave empty directories in packages -#-- zipman: Compress manual (man and info) pages in MAN_DIRS with gzip -#-- purge: Remove files specified by PURGE_TARGETS -#-- upx: Compress binary executable files using UPX -#-- optipng: Optimize PNG images with optipng -#-- debug: Add debugging flags as specified in DEBUG_* variables -# -OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !upx !optipng !debug) +#-- emptydirs: Leave empty directories in packages +#-- zipman: Compress manual (man and info) pages in MAN_DIRS with gzip +#-- purge: Remove files specified by PURGE_TARGETS +#-- upx: Compress binary executable files using UPX +#-- optipng: Optimize PNG images with optipng +#-- debug: Add debugging flags as specified in DEBUG_* variables +#-- autolibprovides: Auto-add so provides +# +OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !upx !optipng !debug !autolibprovides) #-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512 INTEGRITY_CHECK=(md5) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 6ededa3..5475bcc 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -48,6 +48,7 @@ declare -r startdir="$PWD" LIBRARY=${LIBRARY:-'@libmakepkgdir@'} +packaging_options+=('autolibprovides') build_options=('ccache' 'distcc' 'buildflags' 'makeflags') splitpkg_overrides=('pkgdesc' 'arch' 'url' 'license' 'groups' 'depends' 'optdepends' 'provides' 'conflicts' 'replaces' 'backup' @@ -944,6 +945,24 @@ find_libdepends() { printf '%s\n' "${libdepends[@]}" } +auto_libprovides() { + local f solib search_paths autolibprovides + + msg2 "$(gettext "Auto-adding libprovides...")" + + # Only search default library paths + search_paths=($(${CC:-gcc} -print-search-dirs | grep '^lib' | sed "s|^libraries: =|:|;s|:| ${pkgdir}|g")) + + for f in $(find ${search_paths[@]} -maxdepth 1 -type f 2>/dev/null); do + # Match solibs, but exclude ones with a relative path to avoid dups + if [[ "$f" =~ \.so ]] && [[ ! "$f" =~ \.\./ ]]; then + solib="${f##*/}" + autolibprovides+=("${solib%.so.*}.so") + fi + done + + printf '%s\n' "${autolibprovides[@]}" +} find_libprovides() { local p libprovides missing @@ -1130,6 +1149,9 @@ write_pkginfo() { printf "size = %s\n" "$size" printf "arch = %s\n" "$pkgarch" + if check_option "autolibprovides" "y"; then + mapfile -t provides < <(auto_libprovides) + fi mapfile -t provides < <(find_libprovides) mapfile -t depends < <(find_libdepends) -- 2.6.1
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@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. Allan
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@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
Allan
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@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:
But it'll still be broken with regard to .SRCINFO generation.
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@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:
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? 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 ?
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@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:
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
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@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:
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
On Oct 19, 2015 8:42 PM, "Mohammad_AlSaleh" <ce.mohammad.alsaleh@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
> 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@gmail.com
> --- > > Side notes: > > 1- I wasn't sure where to define the option. Since all
> 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
names options that
implements 'autolibdepends' are available here:
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.
participants (4)
-
Allan McRae
-
Dave Reisner
-
Mohammad Alsaleh
-
Mohammad_AlSaleh