4

On arch, when using makepkg to build a pacman-installable .pkg.tar.xz file from source... If it's an AUR "-git" source rather than an upstream release, is there a way to (after the first makepkg) do a git pull and let the build system handle what actually has to be rebuilt? (For a situation where perhaps very often you'd want to install the newest git source.)

I don't see how to avoid having makepkg download a new git repo every time, and rebuild everything from scratch every time.

user1902689
  • 1,178
  • 3
  • 12
  • 23
  • I know, right? Man, if it just stored the repo and did `git pull` instead of `git clone`, we'd already save gobs of time! – PythonNut Jun 26 '15 at 04:28
  • If you want a source tree, you use [ABS](https://wiki.archlinux.org/index.php/Arch_Build_System) *(especially look to the `asp` link at the bottom)*. But even if that is cobbled - how should it work, anyway? a package manager tracks whole, pre-compiled binary packages, and a vcs maintains a versioning tree for source code branches. They seem to be at cross-purposes to me, and i'd think you'd want one or the other. – mikeserv Jun 26 '15 at 04:48
  • @mikeserv - I'm confused/must be missing something. Let's say I choose to upgrade glibc from the version in arch core to upstream git master. Don't I ultimately need to install the binaries through `pacman` so it can properly uninstall the old one and track dependencies? So, if I want to install something that doesn't exist as an arch pre-compiled binary, don't I need to run `makepkg` (or perhaps ABS instead) to make the .pkg.tar.xz to install via pacman? If I run `makepkg` with a PKGBUILD file getting the source from git, it clones each time and builds fresh, rather than pulling and re-making – user1902689 Jun 26 '15 at 06:43
  • Maybe - if you don't just leave em in the tree. Why do they have to be in`/usr/bin` and things? And if they do - just symlink it. Put a little symlink update script that runs with config in the root of every `git` dir and do the thing. – mikeserv Jun 26 '15 at 06:47

1 Answers1

1

Makepkg doesn't clone the repository anew every time, there's a check for an already existing clone in its source. If a non-empty clone is found that has the correct remote URL, all makepkg does is fetch the new commits. This will look like the following in makepkgs output:

==> Retrieving sources...
-> Updating mpd-git git repo...
Fetching origin
remote: Compressing objects: 100% (91/91), done.
remote: Total 481 (delta 392), reused 479 (delta 390)
Receiving objects: 100% (481/481), 64.87 KiB | 0 bytes/s, done.
Resolving deltas: 100% (392/392), completed with 99 local objects.
From file:///home/wieland/dev/mpd
   cd1148c..3fa4dad  master     -> master
   cd1148c..3fa4dad  origin/master -> origin/master
   0d7ee2b..b0ff3bc  origin/v0.19.x -> origin/v0.19.x
 * [new tag]         v0.19.10   -> v0.19.10

Unless you pass --clean or --cleanbuild to makepkg, it will also not remove the source directory used for building the package, so in theory, you would not need to rebuild the whole package. However, there might be cases where the configure script or other scripts called in build() cause the build process to recompile everything.

Wieland
  • 6,353
  • 3
  • 28
  • 31
  • Ahh, I see. The package I'm currently working on is gcc, which of course takes a really long time to rebuild from scratch every time. You're right. gcc's PKGBUILD has `configure` in build(). Would it be better to move it to prepare() ? Won't the buildsystem run configure if needed? Or would this have negative side effects? – user1902689 Jun 27 '15 at 21:01
  • I'm sorry, but I don't have enough knowledge about makepkg or gccs build system to answer that question. – Wieland Jun 28 '15 at 18:34