Exploring the PKGBUILD Arch script

captain-sensible

Well-Known Member
Joined
Jun 14, 2019
Messages
2,910
Reaction score
1,973
Credits
18,114
[This is going to be a work in progress, edited a few times since i need to re-run pkgbuild to get output and correct mistakes]

I used to be a Slackware user and the day I got my head around a SlackBuild script was when one of the core contributors put it to me succinctly and simply like this:
“Its just a controlled and regulated way of using ./configure, make, make install and that the result is a package that when installed the system knows about it, and it can be cleanly removed if required. “
I expect that there would be a common theme of approach to building packages manually with Arch- but lets see.

When a package isn’t available via pacman you can look into the AUR of Arch (Arch User Repository) which hosts additional packages which can be installed on Arch vanilla but which are not “official packages”.

I came across this page which lists GNU software - https://www.gnu.org/manual/blurbs.html

I shimmed down it and noted Moe ; thinking that might be a candidate for me to play with , using a PKGBUILD.

I found that it wasn’t available via pacman BUT that somebody has already submitted it to AUR. Never mind I decided to avoid looking at their approach since it would probably confuse me and see if I could come up with a minimal PKGBUILD script and get it working.

A requirement near the top of priorities is to understand what a recent release is called ; at what location it can be obtained from and how is that information going to be transferred to a pkgbuild script.

The blurb for Moe is at : https://www.gnu.org/software/moe/ and a source location at : http://mirror.koddos.net/gnu/moe/ So there is a recent release dated 2021-01-03 18:49 of only 87K and called moe-1.11.tar.lz

Now its best to follow experience and advice and the general consensus is to keep things tidy and in one place by having a directory called “abs” in your home directory. Inside abs will be placed sub directories with names of other software you might want to build.

This is the structure for me is this :
Code:
  home
|
abs
├── gnurobots
├── latex2html
├── moe
└── sed

whats going to happen is that we are going to put a tailor made (for moe) PKGBUILD script in the directory called moe. We will use it to obtain our source code for moe and build a .zst file which can be installed using pacman.

Lets have a look at my basic script.
Code:
# R & D by andy brookes aka captain sensible
pkgname="moe"
pkgver=1.11
pkgrel=9
pkgdesc="Moe is a GNU, powerful but simple to use text editor \n Moe features multiple windows, unlimited undo redo, unlimited line length, global search and replace, and more.   "
arch=("x86_64")
license=('GPL')
source=("http://mirror.koddos.net/gnu/moe/$pkgname-$pkgver.tar.lz")
build() {
        cd "$pkgname-${pkgver}"
        ./configure --prefix=/usr
        make
}
package() {
        cd "$pkgname-${pkgver}"
        make DESTDIR="$pkgdir" install
}


Lets break it down:

The software we are trying to get is a simple text editor; its called "moe" but as its constandly developed it can't be just called moe so has version control applied and also the source is compacted conveniently for download. in the script unless your used to bash , "pkgname" is actually a variable; an equivalence for a variable in php would be $pkgname. using the equals sign "=" the variable "pkgname" is given the value of "moe"
The next line mentioning the variable "pkgver" means what are they calling it on the repo ? well we know that , its "1.11". So the translation of :

Code:
$pkgname-$pkgver.tar.lz

is just moe-1.11.tar.lz

The reason for working this way is that its easier to manipulate stuff using variables , which if needed can have their values changed.

Code:
pkgrel=9

here i'm basically saying that this is the 9th build of the source in a an installable pkg. I made it 9 , so that i can distinguish from the official AUR package for moe and see if mine installs and works

Code:
source=("http://mirror.koddos.net/gnu/moe/$pkgname-$pkgver.tar.lz")

thats the location where you can get the source for moe. if you click on the link listed in one of the first few paragraphs, shimmy down to moe-1.11.tar.lz mouse, right click , copy link you will see its the same as i have typed above .

Now the parts named "build" and "package" are functions ; what they basically do is carry out the traditional way of installing source code via , ./configure , make , make install.

The difference between as i see it between a SlackBuild script and the Arch way is that the program called "makepkg" which should be on your system is called from the slackbuild; whereas with Arch you have to call makepkg from in this case , the moe sub-directory , which is located in abs directory. When called makepkg will look for a pkgbuild script and use it, which is what i'm going to do now.

I open a terminal and change directory to /abs/moe I now run the command:
Code:
makepkg -g >> PKGBUILD && makepkg                       (06-27 13:25)

Here i evoke makepkg with the g flag; its going to download the source file, generate a checksum for the file and put that info back into the pkgbuild script and then run makepkg on the new pkgbuild script . My pkgbuild script now looks like :

Code:
# R & D by andy brookes aka captain sensible


pkgname="moe"
pkgver=1.11
pkgrel=9
pkgdesc="Moe is a powerful but simple to use text editor \n  Moe features multiple windows, unlimited undo redo, unlimited line length, global search and replace, and more.   "
arch=("x86_64")
license=('GPL')
source=("http://mirror.koddos.net/gnu/moe/$pkgname-$pkgver.tar.lz")




build() {
        cd "$pkgname-${pkgver}"
        ./configure --prefix=/usr
        make
}

package() {
        cd "$pkgname-${pkgver}"
        make DESTDIR="$pkgdir" install
}
sha256sums=('0efbcbcf5a4a8d966541c6cb099ba0ab6416780366dbce82d9ff995a85a5e2f9')


If i look into the moe directory the contents are now:

Code:
abs
└── moe
    ├── moe-1.11-9-x86_64.pkg.tar.zst
    ├── moe-1.11.tar.lz
    ├── pkg
    ├── PKGBUILD
    ├── README.txt
    └── src

So a package called moe-1.11-9-x86_64.pkg.tar.zst has been created ; lets install it :
Code:
sudo pacman -U moe-1.11-9-x86_64.pkg.tar.zst


When i ran that command i got the text in image pacman_u.png


i typed y and hit return key.

Now lets see if it installed and what we can find out.

To get info on moe (installed i run) :

Code:
sudo pacman -Qi moe                                     (06-27 13:39)

The output i got is in the image pacman _Qi_moe

its shows
Version : 1.11-9
and also "unknown packager" - me. Thats definitely the package i created ; i know that because the official AUR is 1.11.1

Now lets see what was put where :


Code:
[andrew@darkstar:abs/moe]$ sudo pacman -Ql  moe                                    (06-27 13:39)
moe /usr/
moe /usr/bin/
moe /usr/bin/moe
moe /usr/etc/
moe /usr/etc/moerc
moe /usr/share/
moe /usr/share/info/
moe /usr/share/info/moe.info.gz
moe /usr/share/man/
moe /usr/share/man/man1/
moe /usr/share/man/man1/moe.1.gz


lets launch moe and see what it looks like (has to be done via a terminal via:


Code:
$ moe


Here is an indication of the simplicity of the Arch package system. The package i created for moe was 1.11-9 I ran :
its a terminal based text editor- you can see Antonio Diaz , who is the creator bottom of text editor window
Code:
yay -Syu

thats not only looks for updates for packages installed via pacman but also for packages created using a pkgbuild script and installed via pacman .After running yay i got:

Code:
:: Searching databases for updates...
:: Searching AUR for updates...
 -> moe: local (1.11-9) is newer than AUR (1.11-1)

its picking up that the package i created manually is ahead of AUR. Its so refreshing clear compared to Debian
 

Attachments

  • moe_one.png
    moe_one.png
    435.5 KB · Views: 428
  • pacman_u.png
    pacman_u.png
    388.9 KB · Views: 395
  • moe_evoked.png
    moe_evoked.png
    309.3 KB · Views: 412
Last edited:


I was going to take over reflector-simple in Arch AUR but it was of a it of a mess; it uses a dev by EndeavourOS team . Also the maintainer put release on it , when in actual fact there were no actual releases.

To cut a long story short i declined it and the maintainer deleted it

Basically reflector-simple was for those that have an aversion to the command line.Reflector-simple
worked on the back of reflector.

I thought I would have a go with python for a program which uses a gui but does not rely on reflector;also that it would be stand alone with everything embedded.

Well just put it up on Source forge ; for those that like testing : https://sourceforge.net/p/fetchmirrorsgui/code/ci/master/tree/


When the basics are working then the next step will be to play with makepkg, but you can put the elf binary straight in /usr/local/bin or /usr/bin without the need for makepkg


I don't know why but the French are first in with downloads
 
Last edited:

Members online


Latest posts

Top