kpcyrd <[email protected]> writes: > https://gitlab.archlinux.org/archlinux/packaging/packages/grep/-/blob/b6557325ffa4abe40e4785823939a42093218acd/PKGBUILD > > source = git+https://git.savannah.gnu.org/git/grep.git?signed#tag=v3.12 > source = git+https://git.savannah.gnu.org/git/gnulib.git > source = https://ftp.gnu.org/gnu/grep/grep-3.12.tar.gz > source = https://ftp.gnu.org/gnu/grep/grep-3.12.tar.gz.sig
Ouch.
Would it work for someone to prepare a tarball "release" of ALL
translation-project translations, perhaps done on a monthly or quarterly
basis? Then that could be packaged separately, and not strongly tied
into the release process of each project. Stronger versioning may be
needed, so that the intended translation for grep 3.12 is actually
picked up. Although I'm not confident that building grep from git --
without any translations available in po/ -- would result in a grep
binary that at run-time would look up the relevant translation files.
Perhaps some hack and/or versioning is needed there too.
This would turn i18n translation file distribution more towards how
centralized manpages are distributed and installed.
> The build steps are then:
>
> 1) In the grep.git repository, link gnulib.git as a submodule. The
> tarball contains files that aren't present in git, and without this
> submodule you won't be able to generate them from source.
Did you consider packaging gnulib separately that installs the gnulib
git bundle? Similar to how the Debian 'gnulib' package provides the
gnulib git bundle. Then you could do a source-level build dependency on
that gnulib package, and something similar to:
git clone /usr/share/gnulib-git.bundle tmp/gnulib
./bootstrap --gnulib-srcdir=tmp/gnulib --pull --skip-po
/Simon
signature.asc
Description: PGP signature
