alpmbuild—a new recipe format for arch packages

pontaoski · 2020-02-03 22:34:52

the big question: "why did you make this we already have PKGBUILDs"

not everyone likes writing PKGBUILDs. this project's target audience is for people who
target many distros for packages with a single build recipe (it's the alpm equivalent of rpmbuild and debbuild).
so why am I posting it here? a project like this is bound to be noticed by packagers sooner or later, and I'd like to
get the first word in.

the post

alpmbuild is a tool for building arch packages from specfiles, the same format used by rpmbuild and debbuild.
alpmbuild's creation expands the amount of users that a single specfile is able to target from "already large" to
"basically everyone using binaries."

but besides that, what does it offer over makepkg?

two things are immediate standouts:
syntax, and ease of subpackaging.

the syntax used is your standard spec syntax, and should be mostly familiar if you know how to read YAML and shell scripts.

subpackages (otherwise known as split packages) are significantly easier to create in alpmbuild's spec syntax than in makepkg's PKGBUILD format.

here's snippets of a PKGBUILD for discover modified to split backends into separate files:

flatpak_backend_files=(
  /usr/lib/qt5/plugins/discover/flatpak-backend.so
  /usr/share/libdiscover/categories/flatpak-backend-categories.xml
  /usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
  /usr/share/applications/org.kde.discover-flatpak.desktop
)

package_discover() {
  ...
  for file in "${flatpak_backend_files[@]}"
  do
    mv $pkgdir/$file ./flatpakbackend
  done
  ...
}

package_discover-backend-flatpak() {
  ...
  for file in "${flatpak_backend_files[@]}"
  do
    mkdir -p $pkgdir/$(dirname $file)
    mv $(basename $file) $pkgdir/$file
  done
  ...
}

it's rather verbose, eh?
here's the same thing, but with alpmbuild's spec syntax.

%files backend-flatpak
/usr/lib/qt5/plugins/discover/flatpak-backend.so
/usr/share/libdiscover/categories/flatpak-backend-categories.xml
/usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
/usr/share/applications/org.kde.discover-flatpak.desktop

in general, split packaging tends to be more powerful and less painful to deal with in alpmbuild than in makepkg;
alpmbuild will be fine with split package scenarios that makepkg will have a hard time with.

i would cover more things in this post, but I already wrote a marketing-style website for alpmbuild that covers most of the
points I would have covered here. so why not go check that out and ask me further questions
if you have anything you would like clarified?

the links

https://alpmbuild.github.io/
https://github.com/alpmbuild/alpmbuild
https://aur.archlinux.org/packages/alpmbuild

Last edited by pontaoski (2020-02-03 22:36:32)

eschwartz · 2020-02-04 07:42:00

Initial reactions:

your marketing website is missing lots of documentation on what the format is,
I don't understand what "we offer directives to make alpmbuild behave more like makepkg" means.
far too much huge-type text, which means I spend more time scrolling up and down than reading the content,
accursed pictures of text, which is just the least friendly thing you could ever do, accessibility-wise, and means no copy-paste,
last, but certainly not least, I'm mortally offended by your gopher mascot. I acknowledge this is a deeply personal opinion, and you are free to ignore it, but nevertheless, there it is -- I find the golang gopher to be profoundly irritating and not in the least "cute".

Overall, it seems like you devoted far more effort to making the website subjectively "cute", rather than focusing on functionality.

...

So, what is the purpose of this project? Is it purely for third-party use? There's prior art in this, see for example https://github.com/jordansissel/fpm and https://gitlab.kitware.com/cmake/cmake/ … uests/4185 -- I'm sure this can help some people fulfill their goals, especially for single-sourcing packages across fedora and archlinux.
I don't foresee this becoming the official way to build packages on archlinux, though.

...

Code review:

I took an extremely cursory look at your commit history, and immediately stumbled across this: https://github.com/alpmbuild/alpmbuild/ … 5bc26aba03

This single line of code triggered the following red flags for me:

just from the commit message, I can tell that you don't allow configurable compression
you use "tar" instead of bsdtar. gnu tar has substandard for some SCHILY.* attributes, and pacman explicitly uses libarchive for reading packages, this *may* become very meaningful if we add xattr support to pacman, and pacman systems must have bsdtar available no matter what. Furthermore, you need bsdtar anyway to generate the .MTREE file.
the .PKGINFO and .MTREE files are added to the archive last, but they must be the first files stored in order for pacman to efficiently extract metadata without decompressing and reading the entire tar file; makepkg explicitly adds these first
the .INSTALL and .CHANGELOG files are not supported at all, it would seem, nor do you generate a .BUILDINFO which makepkg does for reproducible build purposes
you package the files by subprocessing in golang to `sh -c "tar ..."` but this will not support fakeroot things, so I will end up with files in /usr/bin owned by the "eschwartz" user.

On the fakeroot note, I find codesearch matches for fakeroot, which you are using completely incorrectly: https://github.com/alpmbuild/alpmbuild/ … ge.go#L503

This is apparently used to execute the specfile analogues to makepkg's prepare/build/package routines, command by command, using: `fakeroot sh -c "..."`, which is totally wrong, since only package() is intended to run via fakeroot, and makepkg does so by recursively invoking itself as "fakeroot makepkg -F" to run both package functions and the bsdtar compression in the same fakeroot process. You can do something similar by using "fakeroot -s state-file -i state-file" across multiple invocations of fakeroot, but you'll also have to actually run "tar -c" under fakeroot too... note the caveat that fakeroot state-files only work if you don't move the files around in the alpmbuild program outside of fakeroot and outside of the sh -c subprocesses; does that %files macro violate this expectation?

...

Spec file format review:

Looking at your examples in https://github.com/alpmbuild/alpmbuild/ … r/examples, you have dropped *sums verification of the source files in both cases. Furthermore, you don't include validpgpkeys support for verifying PGP signatures. Failure to even check whether the file downloaded correctly is such a dealbreaking dealbreaker that for this reason alone it must not be used.

DESTDIR=$PREFIX PREFIX=%{_prefix}

Why is this naming so completely gross?

$PREFIX is an environment variable that represents the DESTDIR packaging root, or $pkgdir in makepkg language,
%{_prefix} is an rpm macro that represents the --prefix option to an autotools configure script or meson.build

Source0: https://github.com/Jguer/yay/archive/v%{version}.tar.gz

%prep
tar -xvf v%{version}.tar.gz

Why must the user manually extract sources? makepkg can intelligently do this itself, or be suppressed from doing so with the noextract array.

You have also dropped renaming the sources to something more unique than v9.4.4.tar.gz, which will cause cached versions of some other software's v9.4.4.tar.gz to be incorrectly detected as the source for this package. Given all work is done in the unconfigurable /home/eschwartz/alpmbuild/buildroot/ directory, which contains the extracted and built copies of all packages that were built, things will certainly clash, unless of course you redownload 500MB sources on every single alpmbuild run and overwrite the cached version.

I tried building and running this software out of morbid interest, and now:

$ ls /home/eschwartz/alpmbuild/buildroot
hello-2.10/  hello-2.10.tar.gz  v9.4.4.tar.gz  yay-9.4.4/

This is pretty... unclean. And also filthies up my $HOME.

Last edited by eschwartz (2020-02-04 07:50:57)

eschwartz · 2020-02-04 08:02:19

pontaoski wrote:

subpackages (otherwise known as split packages) are significantly easier to create in alpmbuild's spec syntax than in makepkg's PKGBUILD format.
here's snippets of a PKGBUILD for discover modified to split backends into separate files:
flatpak_backend_files=(
  /usr/lib/qt5/plugins/discover/flatpak-backend.so
  /usr/share/libdiscover/categories/flatpak-backend-categories.xml
  /usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
  /usr/share/applications/org.kde.discover-flatpak.desktop
)

package_discover() {
  ...
  for file in "${flatpak_backend_files[@]}"
  do
    mv $pkgdir/$file ./flatpakbackend
  done
  ...
}

package_discover-backend-flatpak() {
  ...
  for file in "${flatpak_backend_files[@]}"
  do
    mkdir -p $pkgdir/$(dirname $file)
    mv $(basename $file) $pkgdir/$file
  done
  ...
}
it's rather verbose, eh?
here's the same thing, but with alpmbuild's spec syntax.
%files backend-flatpak
/usr/lib/qt5/plugins/discover/flatpak-backend.so
/usr/share/libdiscover/categories/flatpak-backend-categories.xml
/usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
/usr/share/applications/org.kde.discover-flatpak.desktop
in general, split packaging tends to be more powerful and less painful to deal with in alpmbuild than in makepkg;
alpmbuild will be fine with split package scenarios that makepkg will have a hard time with.

Instead of writing a makepkg competitor from scratch, to do something that is currently impossible, why not consider writing a small amount of new code to be upstreamed into makepkg? Example PKGBUILD:

stage_install() {
  cd ${pkgname}-${pkgver}

  make install DESTDIR="${pkgdir}"
}

package_discover-backend-flatpak() {
  cd "${pkgdir}"

  pickfiles=(
    usr/lib/qt5/plugins/discover/flatpak-backend.so
    usr/share/libdiscover/categories/flatpak-backend-categories.xml
    usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
    usr/share/applications/org.kde.discover-flatpak.desktop
  )
}

Then makepkg would automatically handle adding these files.

This potential feature request has been brought up multiple times and died because no active contributors care about the feature. Between the split packages that require building/installing twice anyway (python/python2) and the ones that support "make -C subdir install" (e.g. gcc, and I'm told kde as well), it's not often a high priority...

Alad · 2020-02-04 10:25:37

Why would "pickfiles" need to be specifically added to makepkg? Since we're talking about Arch, which has GNU coreutils, you could do something like this:

_pickfiles=(your face is)
install -Dm755 "${_pickfiles[@]}" -t "$pkgdir"/usr/share/face

Furthermore, if adding such a "feature", do you stop there? Distros like frugalware or void take the idea much further and abstract commands/file paths for specific languages like python, too.

Hypothetical question since (to my relief) there's ostensibly nobody wanting to merge such a feature. Feel free to drop a few links to where it has been proposed, though.

Last edited by Alad (2020-02-04 10:26:55)

Allan · 2020-02-04 12:55:46

eschwartz wrote:

This potential feature request has been brought up multiple times and died because no active contributors care about the feature. Between the split packages that require building/installing twice anyway (python/python2) and the ones that support "make -C subdir install" (e.g. gcc, and I'm told kde as well), it's not often a high priority...

I know one contributor who had a working patch and never submitted and now it is lost...

eschwartz · 2020-02-04 16:40:49

Alad wrote:

Why would "pickfiles" need to be specifically added to makepkg? Since we're talking about Arch, which has GNU coreutils, you could do something like this:
_pickfiles=(your face is)
install -Dm755 "${_pickfiles[@]}" -t "$pkgdir"/usr/share/face

For two reasons:

the command line you offer doesn't work the way you imply it does, as a single `install ... -t ...` invocation will flatten the hierarchy of files to be installed, and install them all directly to /usr/share/face, which I suppose is why you didn't suggest installing to `-t "$pkgdir"`; unfortunately that makes it totally useless for the purpose of installing files as diverse as:
/usr/lib/qt5/plugins/discover/flatpak-backend.so
/usr/share/libdiscover/categories/flatpak-backend-categories.xml
/usr/share/metainfo/org.kde.discover.flatpak.appdata.xml
/usr/share/applications/org.kde.discover-flatpak.desktop
So it is not a one-liner, instead, it is a three-liner, which is only simpler than the OP's "it's rather verbose" idea, by *one* line:
```
for i in array; do
  install -Dm755 "$i" "$pkgdir/$i"
done
```
any file or directory in the installation hierarchies can have arbitrary permissions or ownership set during the normal package_*() routines, and these must be preserved when migrating to a single installation hierarchy with file manifests per split package. This is the only actually hard part of the whole thing, and it is in fact quite annoyingly hard. One example of it breaking is that you have now installed all files using "install"s default 755 executable permissions... to /usr/share? mkdir -p + mv / cp would preserve the initial file permissions for at least the final pathname component.

Furthermore, if adding such a "feature", do you stop there? Distros like frugalware or void take the idea much further and abstract commands/file paths for specific languages like python, too.

Abstracting away commands so that you don't know what "vman foo.1" does is pretty different and I'd definitely stop before there. FYI: that's also what rpm macros do, though at least you know that %make_build and %make_install are not actually shell commands, and therefore you should look up its definition in the rpm manual, which will not mention anything, but you'll eventually find out from google that they are defined in /usr/lib/rpm/macros, as (respectively) %{__make} %{_make_output_sync} %{?_smp_mflags} %{_make_verbose} and %{__make} install DESTDIR=%{?buildroot} INSTALL="%{__install} -p".

Regardless, this does not abstract away any build commands, the user must setup the installation pkgdir themselves and define a makepkg metadata array which is clearly part of makepkg's internal API and has very limited scope: to filter in exactly those files from a multi-package installation root.

eschwartz · 2020-02-05 04:30:58

https://github.com/alpmbuild/alpmbuild/ … f3350d3bf6

Thank you for (partially) fixing the archive creation command to be prefixed with fakeroot (and fixing several other things I pointed out there). alpmbuild now successfully builds a minimally viable package (files are not owned by the build user):

$ bsdtar -tvf /home/eschwartz/alpmbuild/packages/hello-2.10-0-x86_64.pkg.tar.zst 
-rw-r--r--  0 root   root      131 Feb  4 23:19 .PKGINFO
-rw-r--r--  0 root   root     4577 Feb  4 23:19 .MTREE
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/bin/
-rwxr-xr-x  0 root   root   128064 Feb  4 23:19 usr/bin/hello
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/info/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/man/
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/man/man1/
-rw-r--r--  0 root   root     1400 Feb  4 23:19 usr/share/man/man1/hello.1
-rw-r--r--  0 root   root      599 Feb  4 23:19 usr/share/info/dir
-rw-r--r--  0 root   root    36438 Feb  4 23:19 usr/share/info/hello.info
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/bg/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ca/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/da/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/de/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/el/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/eo/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/es/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/et/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/eu/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/fa/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/fi/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/fr/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ga/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/gl/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/he/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/hr/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/hu/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/id/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/it/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ja/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ka/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ko/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/lv/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ms/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/nb/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/nl/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/nn/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/pl/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/pt/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/pt_BR/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ro/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/ru/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/sk/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/sl/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/sr/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/sv/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/th/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/tr/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/uk/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/vi/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/zh_CN/
drwxr-xr-x  0 root   root        0 Feb  4 02:14 usr/share/locale/zh_TW/
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/zh_TW/LC_MESSAGES/
-rw-r--r--  0 root   root     2754 Feb  4 23:19 usr/share/locale/zh_TW/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/zh_CN/LC_MESSAGES/
-rw-r--r--  0 root   root     2603 Feb  4 23:19 usr/share/locale/zh_CN/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/vi/LC_MESSAGES/
-rw-r--r--  0 root   root     3863 Feb  4 23:19 usr/share/locale/vi/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/uk/LC_MESSAGES/
-rw-r--r--  0 root   root     4531 Feb  4 23:19 usr/share/locale/uk/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/tr/LC_MESSAGES/
-rw-r--r--  0 root   root     2861 Feb  4 23:19 usr/share/locale/tr/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/th/LC_MESSAGES/
-rw-r--r--  0 root   root     5017 Feb  4 23:19 usr/share/locale/th/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/sv/LC_MESSAGES/
-rw-r--r--  0 root   root     1092 Feb  4 23:19 usr/share/locale/sv/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/sr/LC_MESSAGES/
-rw-r--r--  0 root   root     4129 Feb  4 23:19 usr/share/locale/sr/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/sl/LC_MESSAGES/
-rw-r--r--  0 root   root     3438 Feb  4 23:19 usr/share/locale/sl/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/sk/LC_MESSAGES/
-rw-r--r--  0 root   root     3361 Feb  4 23:19 usr/share/locale/sk/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ru/LC_MESSAGES/
-rw-r--r--  0 root   root     4226 Feb  4 23:19 usr/share/locale/ru/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ro/LC_MESSAGES/
-rw-r--r--  0 root   root      735 Feb  4 23:19 usr/share/locale/ro/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/pt_BR/LC_MESSAGES/
-rw-r--r--  0 root   root     3393 Feb  4 23:19 usr/share/locale/pt_BR/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/pt/LC_MESSAGES/
-rw-r--r--  0 root   root      460 Feb  4 23:19 usr/share/locale/pt/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/pl/LC_MESSAGES/
-rw-r--r--  0 root   root     3361 Feb  4 23:19 usr/share/locale/pl/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/nn/LC_MESSAGES/
-rw-r--r--  0 root   root      731 Feb  4 23:19 usr/share/locale/nn/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/nl/LC_MESSAGES/
-rw-r--r--  0 root   root     3499 Feb  4 23:19 usr/share/locale/nl/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/nb/LC_MESSAGES/
-rw-r--r--  0 root   root     3331 Feb  4 23:19 usr/share/locale/nb/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ms/LC_MESSAGES/
-rw-r--r--  0 root   root     1167 Feb  4 23:19 usr/share/locale/ms/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/lv/LC_MESSAGES/
-rw-r--r--  0 root   root     3475 Feb  4 23:19 usr/share/locale/lv/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ko/LC_MESSAGES/
-rw-r--r--  0 root   root     1201 Feb  4 23:19 usr/share/locale/ko/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ka/LC_MESSAGES/
-rw-r--r--  0 root   root      898 Feb  4 23:19 usr/share/locale/ka/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ja/LC_MESSAGES/
-rw-r--r--  0 root   root      705 Feb  4 23:19 usr/share/locale/ja/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/it/LC_MESSAGES/
-rw-r--r--  0 root   root      700 Feb  4 23:19 usr/share/locale/it/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/id/LC_MESSAGES/
-rw-r--r--  0 root   root     3354 Feb  4 23:19 usr/share/locale/id/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/hu/LC_MESSAGES/
-rw-r--r--  0 root   root     3682 Feb  4 23:19 usr/share/locale/hu/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/hr/LC_MESSAGES/
-rw-r--r--  0 root   root     2927 Feb  4 23:19 usr/share/locale/hr/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/he/LC_MESSAGES/
-rw-r--r--  0 root   root      710 Feb  4 23:19 usr/share/locale/he/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/gl/LC_MESSAGES/
-rw-r--r--  0 root   root     3527 Feb  4 23:19 usr/share/locale/gl/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ga/LC_MESSAGES/
-rw-r--r--  0 root   root     1142 Feb  4 23:19 usr/share/locale/ga/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/fr/LC_MESSAGES/
-rw-r--r--  0 root   root     3515 Feb  4 23:19 usr/share/locale/fr/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/fi/LC_MESSAGES/
-rw-r--r--  0 root   root     2576 Feb  4 23:19 usr/share/locale/fi/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/fa/LC_MESSAGES/
-rw-r--r--  0 root   root      849 Feb  4 23:19 usr/share/locale/fa/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/eu/LC_MESSAGES/
-rw-r--r--  0 root   root      753 Feb  4 23:19 usr/share/locale/eu/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/et/LC_MESSAGES/
-rw-r--r--  0 root   root     2620 Feb  4 23:19 usr/share/locale/et/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/es/LC_MESSAGES/
-rw-r--r--  0 root   root     3413 Feb  4 23:19 usr/share/locale/es/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/eo/LC_MESSAGES/
-rw-r--r--  0 root   root     2541 Feb  4 23:19 usr/share/locale/eo/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/el/LC_MESSAGES/
-rw-r--r--  0 root   root     3329 Feb  4 23:19 usr/share/locale/el/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/de/LC_MESSAGES/
-rw-r--r--  0 root   root     3518 Feb  4 23:19 usr/share/locale/de/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/da/LC_MESSAGES/
-rw-r--r--  0 root   root     2747 Feb  4 23:19 usr/share/locale/da/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/ca/LC_MESSAGES/
-rw-r--r--  0 root   root     2809 Feb  4 23:19 usr/share/locale/ca/LC_MESSAGES/hello.mo
drwxr-xr-x  0 root   root        0 Feb  4 23:19 usr/share/locale/bg/LC_MESSAGES/
-rw-r--r--  0 root   root     1316 Feb  4 23:19 usr/share/locale/bg/LC_MESSAGES/hello.mo

Note that chown calls in %install (for example as part of make install), unlike similar calls in makpekg's package() function, still do not take effect in the final built package, which means that many complex package tasks cannot yet be fulfilled.

Alad · 2020-02-05 19:55:49

eschwartz wrote:

Abstracting away commands so that you don't know what "vman foo.1" does is pretty different and I'd definitely stop before there. FYI: that's also what rpm macros do, though at least you know that %make_build and %make_install are not actually shell commands, and therefore you should look up its definition in the rpm manual, which will not mention anything, but you'll eventually find out from google that they are defined in /usr/lib/rpm/macros, as (respectively) %{__make} %{_make_output_sync} %{?_smp_mflags} %{_make_verbose} and %{__make} install DESTDIR=%{?buildroot} INSTALL="%{__install} -p".
Regardless, this does not abstract away any build commands, the user must setup the installation pkgdir themselves and define a makepkg metadata array which is clearly part of makepkg's internal API and has very limited scope: to filter in exactly those files from a multi-package installation root..

Fair enough. Thanks for uncovering the details.

Last edited by Alad (2020-02-05 19:56:07)

Arch Linux

#1 2020-02-03 22:34:52