PKGBUILD review request: mkuki

foxite · 2021-09-17 13:50:33

mkuki is a tool that I wrote that generates a unified kernel image that can be booted directly on a UEFI-capable machine. mkuki can also sign the resulting efi binary so that it can be used on a machine with secure boot enabled. I have been using it for several weeks and it works perfectly. The only downside as of right now is that I have not been able to automate its use after every kernel/initramfs upgrade, because these tend to happen at the same time (especially if you use NVIDIA's proprietary driver) and running this program twice causes the backup of the existing efi binary to be overwritten.

PKGBUILD is pretty simple, but for my first ever submission I thought it would be a good idea to seek feedback regardless.

# Maintainer: Foxite <the@dirkkok.nl>
pkgname=mkuki
pkgver=0.1.0
pkgrel=1
pkgdesc='Build and sign a Unified Kernel Image'
url='https://github.com/Foxite/mkuki'
arch=('any')
license=('MIT')
changelog=CHANGELOG
source=("$pkgname-$pkgver.tar.gz::https://github.com/Foxite/mkuki/releases/download/v$pkgver/v$pkgver.tar.gz"
		"$pkgname-$pkgver.tar.gz.gpg::https://github.com/Foxite/mkuki/releases/download/v$pkgver/v$pkgver.tar.gz.gpg"
		'LICENSE')
depends=('binutils' 'sed' 'awk' 'coreutils' 'util-linux')
makedepends=('perl')
optdepends=('sbsigntools: for signing EFI images')
md5sums=('2288302db03e8f002c7e31d53cd5b3ec'
         'cc4df7bd56fefab2125a56e1a75cfedf'
         'e4c03e95973ad812543b74a795f7aa7c')
sha256sums=('719046c211b653b1d2597f6c9aa362ca2a2b191a1efa3ddf4f26d3e0f00d6daf'
            '5a0229f250a31029a1c8193baf05e13cd1e00cd5c20d29b629d3b6153b48b2b3'
            '69b5a05de839b9b2d2fe796dcdc4867a5dd6f9a459317b61df8b05160a86fb72')
validpgpkeys=('EE05738A0F76012F5CF673DF60BD929EFA66E01F') # Foxite <the@dirkkok.nl>

build() {
	pod2man --section=1 --release="$pkgver" $pkgname.pod | gzip > $pkgname.1.gz
}

package() {
	install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
	install -Dm755 $pkgname "$pkgdir/usr/bin/$pkgname"
	install -Dm744 $pkgname.1.gz "$pkgdir/usr/share/man/man1/$pkgname.1.gz"
}

By the way, if this package makes it onto the AUR, would it look bad if I added a note on the wiki saying that the process of building a UKI can be automated using this tool?

Last edited by foxite (2021-09-18 12:48:36)

loqs · 2021-09-17 21:48:39

epoch=0

Not required

license=('MIT')

MIT is one of the special case licenses and needs to be included in the package, see PKGBUILD#license.

source=("https://github.com/Foxite/mkuki/releases/download/v$pkgver/v$pkgver.tar.gz"{,.gpg})

v0.1.0.tar.gz and v0.1.0.tar.gz.gpg are not unique I would suggest renaming the download to include $pkgname.

	install -Dm755 $pkgname $pkgdir/usr/bin/$pkgname

Please quote uses of $pkgdir and $srcdir as they may expand to paths including spaces.

foxite · 2021-09-17 22:15:23

Thanks, I have updated the OP with your feedback.

I noticed I was being inconsistent with substituting "mkuki" for "$pkgname", so I made sure to do it everywhere. However I'm wondering if it even makes sense to do so. I only did it because I saw other PKGBUILDs do the same thing, what exactly is the reason for doing it?

Ammako · 2021-09-17 22:21:27

foxite wrote:

I noticed I was being inconsistent with substituting "mkuki" for "$pkgname", so I made sure to do it everywhere. However I'm wondering if it even makes sense to do so. I only did it because I saw other PKGBUILDs do the same thing, what exactly is the reason for doing it?

It's just in case you decide (or need) to change the package name later down the line, it ensures that the change is properly reflected everywhere without having to hunt down every occurence in the PKGBUILD. For smaller files it's not as big of a deal, but it's nice to have for convenience.

Trilby · 2021-09-17 23:55:05

foxite wrote:

I only did it because I saw other PKGBUILDs do the same thing, what exactly is the reason for doing it?

Some of us also have a fairly consistent "workflow" for various projects, so using variables for these facilitates importing a PKGBUILD from an old project into a new project requiring minimal changes: sometimes just the one actual name that is used to set the variable and a description field.

It appears some dependencies are missing - at leask awk and sed are used in the script.

Last edited by Trilby (2021-09-18 00:01:10)

foxite · 2021-09-18 12:37:53

Trilby wrote:

It appears some dependencies are missing - at leask awk and sed are used in the script.

These are required by base, which also provides bash (as sh), coreutils and util-linux (getopt). Even though the wiki says not to rely on transitive dependencies, it seems a little silly to require those. Is there a list somewhere of packages that are "implicitly" required, or am I actually supposed to include these as well?

Slithery · 2021-09-18 12:43:54

You can't assume that all packages in base are installed on every system, you need to list the dependencies that your program uses.

foxite · 2021-09-18 12:49:50

Dependencies added as instructed.

Out of curiousity, under what circumstances is a system that's running Arch going to be missing a non-broken installation of base?

Trilby · 2021-09-18 13:04:06

I haven't actually uninstalled them, but I have no use for the gawk or gnu version of sed on my system. PKGBUILDs can also be used on other distros that may have a different base meta-package, or a base group, or none at all.

But the reason I actually noticed this is because you *did* (properly) list binutils ... but it seemed odd that that would be all that was required. One could argue that binutils wouldn't need to be listed as it's a dependency of gcc which all archers should have installed. But this is a bad arguement as "should" or really "should most likely" is not the same as "must". It's a bit of a nit to pick, but direct dependencies should always be listed without assumptions that other people's systems are configured the same as ours.

As an example of where these assumptions goes wrong, even the current wiki page on PKGBUILDs makes the a silly and annoying assumption in discussing dependencies of glibc essentially suggesting that any glibc dependencies need not be listed "because every system needs some C library" - but glibc isn't the only libc game in town: "some C library" doesn't necessarily mean glibc.

To play devils advocate, though, many of these guidelines were written when base was a group with a wide range of packages useless on many people's systems. Now base is a meta-package with a much smaller list of members. So with this change, I think it could quite logically be argued that assuming base packages should not be listed in depends for the same reason base-devel packages are not to be listed in madedepends. While I think a logical case for this could be made, I'd not favor it - but in either case, until such a case is made and passed, all direct dependencies should be listed.

Last edited by Trilby (2021-09-18 13:08:04)

foxite · 2021-09-18 13:10:25

I see. The reason I listed binutils is because the first time I followed the wiki article on producing a UKI, I had to figure out where objcopy comes from and then install binutils, as it was a fresh system that didn't have gcc yet (or even had a bootloader installed, I was still running inside chroot from the install media).

Arch Linux

#1 2021-09-17 13:50:33

PKGBUILD review request: mkuki

#2 2021-09-17 21:48:39

Re: PKGBUILD review request: mkuki

#3 2021-09-17 22:15:23

Re: PKGBUILD review request: mkuki

#4 2021-09-17 22:21:27

Re: PKGBUILD review request: mkuki

#5 2021-09-17 23:55:05

Re: PKGBUILD review request: mkuki

#6 2021-09-18 12:37:53

Re: PKGBUILD review request: mkuki

#7 2021-09-18 12:43:54

Re: PKGBUILD review request: mkuki

#8 2021-09-18 12:49:50

Re: PKGBUILD review request: mkuki

#9 2021-09-18 13:04:06

Re: PKGBUILD review request: mkuki

#10 2021-09-18 13:10:25

Re: PKGBUILD review request: mkuki

Board footer