kpcyrd wrote: > Arch Linux also ran into this problem with many GNU projects when trying to > implement the "Upstream package sources" RFC: > > https://rfc.archlinux.page/0046-upstream-package-sources/ > > The only practical solution we found was "using both git and the tarball as > build input".
Yes, this is a reasonable solution for packages which don't store their PO files in some git repository. > The build steps are then: > ... > 3) Run `./configure` and `make` in the git repository checkout > > 4) In the extracted tarball, navigate to the po/ directory and run `msgfmt` > on > each .po file to generate the respective .mo file. This step 4 is incomplete: It should merge each .po file against the <domain>.pot POT file (either from the tarball or built in step 3) using 'msgmerge', and then only convert the result to .mo format using 'msgfmt'. Otherwise the process is vulnerable to attacks by malicious translators [1]. > The files inside of `grep-3.12.tar.gz` could in theory get repacked into > `grep-translations-3.12.tar.gz`, even though anybody could do this, this > would > ideally be done by the upstream developers themselves so the file can carry a > valid signature. It is unrealistic and not appropriate to expect that upstream package maintainers do this. Internationalization in GNU is designed to be as easy for programmers and maintainers as possible; otherwise the adoption rate might suffer. Requiring that the maintainers upload two tarballs instead of one, just for internationalization, would make internationalization less attractive to the maintainers. Bruno [1] https://sourceware.org/pipermail/libc-alpha/2026-September/180555.html
