除了CTF外我其实还是一个特别喜欢搞linux的一个垃圾，在2020年11月份左右我将电脑系统换到了kali并且因为当时不会装双系统把windows搞没了，不过用过一段时间发现linux的操作逻辑更加的符合我。
依赖 linux的依赖问题一直是被人诟病的，尤其是debian系的(arch系我感觉几乎没遇到过依赖问题)，在进行安装的总是会出来这个套那个，导致我以前使用ubuntu时安装一个程序可能得花上一下午的时间，而且几乎全部时间都在解决依赖问题。
那么问题来了，依赖到底是什么？
首先需要说明的是windows和linux其实都是存在依赖问题的，比如我以前在windows虚拟机里面运行ida的时候就会出现依赖问题，不过网上都有现成的包直接安装就好。虽然按理来说linux也存在依赖的包，但是为什么linux的依赖问题会比windows更加经常发生呢？
举个例子：现在运行一个程序需要依赖a-1，我使用windows找到了这个依赖的安装包，实际上这个安装包安装下来的是a-1,a-2,,,,a-30。但是纯纯的linux只会帮你安装a-1，下一次遇到需要a-12的时候，windows不会报错但是linux又需要安装另外版本的依赖了。
上面的看过了之后就大概对linux的依赖问题有一定了解了，那么为了更好的了解依赖问题我们首先需要知道
安装一个包的过程
首先可以看到linux和window的不同，linux的安装包是真的非常单纯的压缩整合到一起，最后由包管理器将不同功能的文件放到不同目录。
在上面这张图里面我们需要重点关注的data.tar.xz
查看其内部可以发现就是一个usr目录
这里就是我们熟悉的desktop，也就是桌面图标
可以看到bin目录是一个链接符号
1 2 tcdy@archlinux /mnt/5F2601400CC8834D/save/usr/bin % ls -l typora lrwxrwxrwx 1 root root 22 Apr 7 10:51 typora -> ../share/typora/Typora
可以看到就是链接到了一个可执行文件，当我们双击文件就可以打开typora了。
找到可执行程序之后只需要使用ldd即可查看需要的依赖
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 tcdy@archlinux ..5F2601400CC8834D/save/usr/share/typora % ldd Typora linux-vdso.so.1 (0x00007ffe581fd000) libffmpeg.so => /mnt/5F2601400CC8834D/save/usr/share/typora/./libffmpeg.so (0x00007fefa6baa000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fefa6b7e000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fefa6b79000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fefa6b1a000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fefa69dc000) libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x00007fefa69d7000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007fefa6807000) libnss3.so => /usr/lib/libnss3.so (0x00007fefa66d4000) libnssutil3.so => /usr/lib/libnssutil3.so (0x00007fefa66a1000) libsmime3.so => /usr/lib/libsmime3.so (0x00007fefa6678000) libnspr4.so => /usr/lib/libnspr4.so (0x00007fefa6636000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007fefa660c000) libatk-bridge-2.0.so.0 => /usr/lib/libatk-bridge-2.0.so.0 (0x00007fefa65d4000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007fefa6581000) ......
可以看到这里甚至于有依赖就在当前目录寻找了
可以看到这里的文件其实也就包含了上面所需要的一部分依赖，其实这也是很多windows程序的思路，如果程序存在很多不常见到的依赖就会把依赖和程序捆绑起来进行安装。
其实到这里大家都大概知道了包管理器在安装程序时到底是干了什么，其实就是将不同功能的程序放进了不同目录。
AUR-PKGBUILD的编写 一样拿typora举例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 _pkgname=typora pkgname="$_pkgname -free" pkgver=0.11.18 pkgrel=2 pkgdesc="A minimal markdown editor and reader." arch=('x86_64' ) filename="typora_${pkgver} _amd64.deb" license=('custom:"Copyright (c) 2015 Abner Lee All Rights Reserved."' ) url="https://typora.io/" depends=('gtk3' 'libxss' ) optdepends=( 'noto-fonts-emoji: Or some other emoji font to see emojis' 'pandoc: Import/export for extra file formats' ) provides=("$_pkgname " ) conflicts=("$_pkgname " ) source =("https://typora.io/linux/$filename " )sha512sums=('8933cb4eab13a37719a3771d14a7a3f5951f6bbce06381ffe37ad5bc3029efed3878723427a4e97b83dbc1d7ccc43b31551b0c336663c843f0e685f8a4e2390e' ) package bsdtar -xf data.tar.xz -C "$pkgdir /" rm -rf "$pkgdir /usr/share/lintian/" chmod 4755 "$pkgdir /usr/share/typora/chrome-sandbox" chmod -R go-w "$pkgdir /usr/share/typora/resources/node_modules" sed -i '/Change Log/d' "$pkgdir /usr/share/applications/typora.desktop" find "$pkgdir " -type d -exec chmod 755 {} \; }
上面的名字，版本，架构什么就不说了，主要关注下面的内容。
首先是这里source，很明显就是再往上的这个文件的deb包，下面sha512sums就是检验码。
srcdir
makepkg 将会把源文件解压到此文件夹或在此文件夹中生成指向 PKGBUILD 里 source 数组中文件的软连接。
pkgdir
makepkg会把该文件夹当成系统根目录，并将软件安装在此文件夹下。
重点就是下面的打包函数，可以看到首先是解压了data.tar.xz这个包带pkgdir。后面就是删除个东西，然后改变权限(可以看到typora是Electron)，下面就是创建图标，最后就是修改pkgdir下目录的权限为755。
关于aur的更多可以看archwiki
sudo免密码 这个是我每次装完系统必干的一件事情，不过经常忘，而且网上的很多东西都不能实现。所以这里自己记录一下
1 2 root ALL=(ALL:ALL) ALL your_username ALL=(ALL) NOPASSWD: ALL
删除/etc/sudoers.d/10-installer
总结 其实程序的安装并没有我以前想象的那么复杂，至少对于linux来说是这样的。如果遇到什么有趣的linux操作我也会及时分享。
