You are not logged in.

#1 2019-07-06 18:36:04

Registered: 2010-01-13
Posts: 32

Unrolling submodules into the source array

Reference: … 2#p1852912

Lone_Wolf wrote:
man 7 gitsubmodules wrote:

      A submodule is a repository embedded inside another repository. The submodule has its own history; the repository it is embedded in is
       called a superproject.

git submodule update --init --recursive

Putting that in the PKGBUILD means you're allowing the sourcecode to download things without your knowledge.
Worse, those extra repos can have their own submodules which bring in extra repos that can also have submodules etc.

Where will they be installed ?
Do they conflict with existing libraires ?
are you violating the licenses of those repos by using them this way ?
Just a few of the questions that can't be answered easily.

For  a single user that builds for their own use this command can be risky, but also very handy.

For PKGBUILDs intended for general public use it is a very bad idea. … Submodules shows an alternative that let's you control the submodules.

Look in the top git repo folder for a .gitmodules file to see what submodules are needed and where the superproject expects them..

I understand the point you're making, listing submodules gives us better control, visibility, security, etc. over what goes into the building of the package.
But slight rant - where does it end?

Case in point: aseprite depends on aseprite/skia (a forked and branched copy of google/skia). The build instructions for skia requires running $(python2 tools/git-sync-deps) which pulls in a bunch of dependencies from external git repos. Functionally, it's similar to git submodule update. If I'm already unrolling the dependencies for the top level project into the PKGBUILD source array, then ideologically, shouldn't I be doing the same for skia? Is it even feasible (I'm not even sure exactly what happens inside git-sync-deps).

DEPS files for skia:

deps = {
  "buildtools"                            : "",
  "common"                                : "",
  "third_party/externals/angle2"          : "",
  "third_party/externals/dng_sdk"         : "",
  "third_party/externals/egl-registry"    : "",
  "third_party/externals/expat"           : "",
  "third_party/externals/freetype"        : "",
  "third_party/externals/googletest"      : "",
  "third_party/externals/harfbuzz"        : "",
  "third_party/externals/icu"             : "",
  "third_party/externals/imgui"           : "",
  # TODO: remove jsoncpp after migrating clients to SkJSON
  "third_party/externals/jsoncpp"         : "",
  "third_party/externals/libjpeg-turbo"   : "",
  "third_party/externals/libpng"          : "",
  "third_party/externals/libwebp"         : "",
  "third_party/externals/lua"             : "",
  "third_party/externals/microhttpd"      : "",
  "third_party/externals/opencl-lib"      : "",
  "third_party/externals/opengl-registry" : "",
  "third_party/externals/piex"            : "",
  "third_party/externals/sdl"             : "",
  "third_party/externals/sfntly"          : "",
  "third_party/externals/spirv-headers"   : "",
  "third_party/externals/spirv-tools"     : "",
  "third_party/externals/swiftshader"     : "",
  #"third_party/externals/v8"              : "",
  "third_party/externals/zlib"            : "",
  "third_party/externals/Nima-Cpp"      : "",
  "third_party/externals/Nima-Math-Cpp" : "",

  "../src": {
    "url": "",
    "condition": "checkout_chromium",

On the other hand, the build instructions for aseprite recommends $(git submodule update --init --recursive). As the packager, I simply follow the build instructions as closely as possible. As a user, I'd expect the packager to do the absolute minimum hackery required to make the package work and insert as little of himself into the process as possible. As a user downloading the an AUR package, I'd expect him to know what goes into it. Would that be good enough?


#2 2019-07-06 18:43:23

Bug Wrangler
Registered: 2012-09-01
Posts: 7,248

Re: Unrolling submodules into the source array

Insane upstreams lead to insane PKGBUILDs. Having to have the source of all of those libs in-tree is insane, make no mistake.


#3 2019-07-06 18:50:23

Registered: 2010-01-13
Posts: 32

Re: Unrolling submodules into the source array

Pasting my first PKGBUILD which I wrote a two days ago for reference.
Tracing those submodules was not fun.

# Maintainer: Justin Wong <jusw85 at hotmail dot com>
# Contributor: Benoit Favre <>
# Contributor: Alexander Rødseth <>
# Contributor: Kamil Biduś <>

pkgdesc='Create animated sprites and pixel art'
arch=('x86_64' 'i686')
license=('BSD' 'custom')
depends=('cmark' 'curl' 'libjpeg-turbo' 'giflib' 'tinyxml' 'pixman' 'libxcursor' 'fontconfig')
makedepends=('git' 'ninja' 'python2' 'clang')
conflicts=("${_pkgname}" "${_pkgname}-gpl"  )

pkgver() {
    cd "${srcdir}/${_pkgname}"
    git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//'

prepare() {
    cd "${srcdir}/${_pkgname}"
    git submodule init
    for (( i=0; i<${#_submodules[@]}; i++ )); do
        git config submodule.${_submodules_path[$i]}.url "${srcdir}/${_submodules[$i]}"
    git submodule update

    cd laf
    git submodule init
    git config submodule.third_party/stringencoders.url "${srcdir}/stringencoders"
    git config submodule.third_party/googletest.url "${srcdir}/googletest"
    git submodule update

    cd "${srcdir}/${_pkgname}"
    patch --strip=1 --input="${srcdir}/desktop.patch"
    mkdir -p build

    cd "${srcdir}/skia"
    python2 tools/git-sync-deps

build() {
    cd "${srcdir}/skia"
    bin/gn gen out/Clang --args='is_debug=false is_official_build=true cc="clang" cxx="clang++" skia_use_system_expat=false skia_use_system_icu=false skia_use_system_libjpeg_turbo=false skia_use_system_libpng=false skia_use_system_libwebp=false skia_use_system_zlib=false'
    ninja -C out/Clang skia

    cd "${srcdir}/${_pkgname}/build"
    cmake \
        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
        -DLAF_OS_BACKEND=skia \
        -DSKIA_DIR="$srcdir/skia" \
        -DSKIA_OUT_DIR="$srcdir/skia/out/Clang" \
        -G Ninja \
    ninja ${_pkgname}

package() {
    cd "${srcdir}/${_pkgname}/build"
    DESTDIR="${pkgdir}" ninja install

    # Remove extraneous files
    rm -f "${pkgdir}"/usr/bin/bsd*
    rm -f "${pkgdir}"/usr/lib/pkgconfig/libarchive.pc
    rm -f "${pkgdir}"/usr/share/man/man1/bsd*

    rm -f "${pkgdir}"/usr/bin/img2webp
    rm -fr "${pkgdir}"/usr/include/webp/
    rm -f "${pkgdir}"/usr/lib/libwebp*
    rm -fr "${pkgdir}"/usr/share/WebP/
    rm -f "${pkgdir}"/usr/share/man/man1/img2webp.1

    rm -f "${pkgdir}"/usr/include/json11.hpp
    rm -f "${pkgdir}"/usr/lib/libjson11.a
    rm -f "${pkgdir}"/usr/lib/pkgconfig/json11.pc

    find "${pkgdir}" -type d -empty -delete

    cd "${srcdir}/${_pkgname}"

    install -Dm644 "src/desktop/linux/${_pkgname}.desktop" "${pkgdir}/usr/share/applications/${_pkgname}.desktop"
    install -Dm644 "src/desktop/linux/mime/${_pkgname}.xml" "${pkgdir}/usr/share/mime/packages/${_pkgname}.xml"
    for i in {16,32,48,64,128,256}; do
        install -Dm644 "data/icons/ase${i}.png" "${pkgdir}/usr/share/icons/hicolor/${i}x${i}/apps/${_pkgname}.png"
        install -Dm644 "data/icons/doc${i}.png" "${pkgdir}/usr/share/icons/hicolor/${i}x${i}/mimetypes/image-x-${_pkgname}.png"
    install -Dm644 "EULA.txt" "${pkgdir}/usr/share/licenses/${pkgname}/EULA"
    install -Dm644 "$srcdir/skia/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"


#4 2019-07-06 21:12:07

Bug Wrangler
Registered: 2012-09-01
Posts: 7,248

Re: Unrolling submodules into the source array

If you're using shared freetype, zlib, etc, why do you need the sources?


#5 2019-07-07 05:43:53

Registered: 2010-01-13
Posts: 32

Re: Unrolling submodules into the source array

I hadn't gotten around to testing which ones could be safely removed. Have updated accordingly. Thanks!


Board footer

Powered by FluxBB