如何制作arch的软件包4

发布网友发布时间：2023-10-14 10:54

共1个回答

热心网友时间：2024-11-30 17:37

现在，你已设好了软件的一些信息——哪儿能下到源文件，包的名称是什么等等。下一步就是如何写出指令去编译、安装你想要打包的程序。一般来讲，在你开始自动打包处理之前，你至少要手动做一次，除非，你很清楚在此之前你所做的一切。但不管怎样你都应该首先说读读这个。很不幸的是，尽管很多程序都可以以“三步曲”——"./configure; make; make install"来安装，但这不是万能的。如果你必须要打补丁才能使之正常工作的话，你的包将变得很丑陋。单凭经验的方法：如果你不能从源码编译程序并将其安装到一个指定的临时子目录下的话，就别去尝试打包了。makepkg中没有能帮你解决源码问题的魔法小精灵。也就是说，你应该下载源码包，解压，记下所有有关编译、安装的命令。PKGBUILD文件中的build函数将精确地重复这一步骤，并在编译完成后将一切捆在一起。现在你可能需要编辑build函数。其实，它用的只是普通的shell命令——遵循bash语法。该函数的基本目的就是自动编译好程序，并且将其安装到新建的软件包目录，使makepkg可以轻松地打包，而不是要将所需的文件从你的系统中一个一个地找出来。一般来说，build函数的第一步就是进入源文件解压后生成的目录。你可以使用$startdir——它代表PKGBUILD所在的目录。你也可以使用之前设置的$pkgname和$pkgver变量。例如，根据makepkg解压生成的目录，build函数的第一个命令可能就是cd $startdir/src/$pkgname-$pkgver，通常都会是这样，除非程序的作者是一个非常非常古怪的人。编译程序就比较难一点了。我想，你应该设法手工编译。因为你不大可能将所有可能需要的步骤都包括进来。这就是希望程序的作者写README和INSTALL文件的原因。现在，你就在这个目录中，你需要给出命令以编译程序。简单时，你只要使用./configure; make，尽管有很多变化——包括ant build或具体的编译软件的gcc命令。简单地说，软件可能不是以源码形式发布，而你必须用sh installer.run的形式运行。你可能需要多研究一下（读README，INSTALL，手册页，可能还要看一看如gentoo的ebuilds，甚至是MAKEFILE或源代码），使其可以正常使用。在某些极端情况下，你可能要修改源代码才能使之正常工作。不管怎样，makepkg需要完全独立地工作——不需要用户的输入。因此，如果你需要编辑Makefile，你应该自己做一个patch，并写在build函数中。或者你必须在build函数中加上sed命令。好的一面就是，如果你已手动编译了整个软件，你只需将你所用的命令列下来就OK了。由于很多软件倾向于安装在/usr/local中，但Archlinux习惯上将软件安装在/usr中，你应该传递相应参数至configure或make命令，仔细一点。PKGBUILD的模板提供了这样的一个例子。这可能与你的实际情况有点差异，但不管怎样，你还有一些工作要做。 build函数的下一步工作就是将已编译好的文件放在一个目录中，以方便makepkg将他们打包。这个目录就是pkg目录，它将被软件的安装进程当成你的系统的根目录。所有将被安装进你的系统的根目录的文件，实际上都会安装在pkg目录中的相同的目录结构中（也就是说，你如果要将myprog这个文件安装到/usr/bin中，它实际上是被安装到$startdir/pkg/usr/bin）。幸运的是，只有一小部分软件需要用户手工拷贝大量文件，但他们也提供某些安装程序来自动完成这一工作——通常都是通过调用"make install"来实现。这很危险，但不管怎样，你会发现如何告知安装进程不要将文件安装到系统的根目录，而是安装到$startdir/pkg。否则，你将发现，最终你得到的只是一空的软件包，而你所要打包的文件已“正确地”安装到了你的系统中。很多时候，你都必须像模板文件中那样在调用"make install"时，加上prefix参数。但这也很可能使程序以完全不同的途径来打包，下面还有一些提示： a.有时，configure脚本接受prefix参数——用来告知将文件安装在何处。例如，你会看到这样的配置：./configure --prefix=$startdir/pkg/usr。 b.有时，可以传递PREFIX选项给make install命令。这种情况下，有时是设置变量，有时是嵌入命令中。更糟的是，你可能必须编辑Makefile（如果软件使用ant的话，就要编辑ant build/properties）。可以使用sed或自己制作补丁。 c.可能也有允许指定安装目录的安装脚本存在。 d.还有一些软件是可以在单独一个目录中运行的。这时只需将其简单地拷入$startdir/pkg/opt即可。就像你可能猜想的那样，你所知道的与你的经验是必不可少的。特别是在你浏览ABS树内的PKGBUILD文件时，这些知识与经验会很用的，因为有些文件是测试用的，其中可能包括一些有用的小窍门或是恶作剧。安装程序时常会很小心地在pkg目录下建立子目录，如果它没有建立相应的子目录，你就会在安装过程中收到许多诸如文件拷贝到不存在的子目录中的错误信息。如果那样的话，在运行安装程序之前，你应该在build函数中加入相应的mkdir命令。实际的目录结构是和软件包相关的，有些程序需要将文件拷入/etc或/usr，有些可能需要使用/bin或/opt。大多数的软件需要建立数个目录，你可以使用mkdir -p $startdir/pkg/OTHER/DIRS/AS/NEEDED，“OTHER/DIRS/AS/NEEDED”代表系统根目录下的目录结构。当你开始写PKGBUILD文件中的build函数时，你需要不停地测试以排除bug。你可以在PKGBUILD所在的目录中运行makepkg来测试。通过一个适当格式的PKGBUILD，很容易就可以创建一个软件包。但如果使用坏掉的或未完成的，这将导致错误。希望这仅仅是个描述性的错误！如果makepkg成功运行完成，它将在你的工作目录中产生一个新得有点闪闪发亮的名为$pkgname-$pkgver.pkg.tar.gz文件。这是一个pacman可安装的软件包，可以通过pacman -U 或pacman -A 来安装或更新，也可以加入到本地或远程的软件包库中。注意，这只意味着软件包已建立，并不意味着它一定可用！如果你不恰当地使用了prefix参数，包中可能只包含目录结构而没有一个文件！你可以使用pacman的查询功能，显示出其中包含的文件清单及其依赖关系，并可与你认为正确的相比较。"pacman -Qlp "和"pacman -Qip "可以完成这个工作。如果包看起来很正常，那就是你所要做的。不管怎样，如果你决定发布软件包或PKGBUILD，你应该强制你自己检查、再检查、再再检查其内容及依赖关系。检查时，应列出所有你的软件包所依赖的包的列表。但depends中只需列出第一层依赖关系即可。这就是说你不必在软件包把所有依赖的包都列进去。如果你的软件所依赖的包中已列出了它所依赖的包——尽管这个包你也需要，但你不必在你的软件包中列出来。例如，gtk2依赖于glib2。列出所有需要的开源C程序，你会发现，gtk2出需要glibc。但glibc不必出现在gtk2的依赖包的名单中，因为glibc是glib2的依赖包，而glib2已经列在gtk2的依赖包的名单中了。有很多工具可用来检查依赖关系，其中就包括Jason Chu的大名鼎鼎的namcap（在线安装：pacman -Sy namcap），还有神秘的ldd。读一读这些程序的手册页及本文结尾处的链接。你应该通读程序的文档及其WEB页（仔细的开发者会提供“dependencies”说明，这会很有帮助的）。同时也要保证软件包可以完美地运行！