标签 打包 下的文章

程序员可以通过 Flatpak 轻松、稳定地发布他们的软件,让他们专注于他们的激情工作:编程。

 title=

如今,人们比以往任何时候都喜爱 Linux。在这个系列中,我将分享使用 Linux 的 21 个不同理由。今天,我将谈一谈是什么让 Linux 的打包成为程序员的理想选择。

程序员喜欢编程。这可能看起来是一个显而易见的说法,但重要的是要明白,开发软件所涉及的不仅仅是编写代码。它包括编译、文档、源代码管理、安装脚本、配置默认值、支持文件、交付格式等等。从一个空白的屏幕到一个可交付的软件安装程序,需要的不仅仅是编程,但大多数程序员宁愿编程也不愿打包。

什么是打包?

当食物被送到商店购买时,它是被包装好的。当直接从农民或从环保的散装或桶装商店购买时,包装是你所带的任何容器。当从杂货店购买时,包装可能是一个纸板箱、塑料袋、一个铁罐等等。

当软件被提供给广大计算机用户时,它也必须被打包起来。像食品一样,软件也有几种打包方式。开源软件可以不进行打包,因为用户在获得原始代码后,可以自己编译和打包它。然而,打包也有好处,所以应用程序通常以某种特定于用户平台的格式交付。而这正是问题的开始,因为软件包的格式并不只有一种。

对于用户来说,软件包使安装软件变得容易,因为所有的工作都由系统的安装程序完成。软件被从软件包中提取出来,并分发到操作系统中的适当位置。几乎没有任何出错的机会。

然而,对于软件开发者来说,打包意味着你必须学会如何创建一个包 —— 而且不仅仅是一个包,而是为你希望你的软件可以安装到的每一个操作系统创建一个独特的包。更加复杂的是,每个操作系统都有多种打包格式和选项,有时甚至是不同的编程语言。

为 Linux 打包

传统上,Linux 的打包方式似乎是非常多的。从 Fedora 衍生出来的 Linux 发行版,如 Red Hat 和 CentOS,默认使用 .rpm 包。Debian 和 Ubuntu(以及类似的)默认使用 .deb 包。其他发行版可能使用其中之一,或者两者都不使用,选择自定义的格式。当被问及时,许多 Linux 用户说,理想情况下,程序员根本不会为 Linux 打包他们的软件,而是依靠每个发行版的软件包维护者来创建软件包。所有安装在 Linux 系统上的软件都应该来自该发行版的官方软件库。然而,目前还不清楚如何让你的软件可靠地被一个发行版打包和包含,更不用说所有的发行版了。

Linux 的 Flatpak

Flatpak 打包系统是为了统一和去中心化 Linux 作为开发者的交付目标而推出的。通过 Flatpak,无论是开发者还是其他人(Linux 社区的成员、不同的开发者、Flatpak 团队成员或其他任何人)都可以自由地打包软件。然后他们可以将软件包提交给 Flathub,或者选择自我托管软件包,并将其提供给几乎任何 Linux 发行版。Flatpak 系统适用于所有 Linux 发行版,所以针对一个发行版就等于针对所有发行版。

Flatpak 技术如何工作

Flatpak 具有普遍吸引力的秘密是一个标准基础。Flatpak 系统允许开发者引用一套通用的软件开发者工具包(SDK)模块。这些模块由 Flatpak 系统的维护者进行打包和管理。当你安装 Flatpak 时,SDK 会根据需要被拉入,以确保与你的系统兼容。任何特定的 SDK 只需要一次,因为它所包含的库可以在任何 Flatpak 中共享。

如果开发者需要一个尚未包含在现有 SDK 中的库,开发者可以在 Flatpak 中添加该库。

结果不言自明。用户可以从一个叫做 Flathub 的中央仓库在任何 Linux 发行版上安装数百个软件包。

开发者如何使用 Flatpak

Flatpak 被设计成可重复的,所以构建过程很容易被集成到 CI/CD 工作流程中。Flatpak 是在一个 YAML 或 JSON 清单文件中定义的。你可以按照我的 介绍性文章 创建你的第一个 Flatpak,你也可以在 docs.flatpak.org 阅读完整的文档。

Linux 让它变得简单

在 Linux 上创建软件很容易,为 Linux 打包也很简单,而且可以自动化。如果你是一个程序员,Linux 使你很容易忘记打包这件事,因为它只需要针对一个系统,并可以整合到你的构建过程中。


via: https://opensource.com/article/21/2/linux-packaging

作者:Seth Kenlon 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

太复杂的包咱们打不来,咱们先从最简单的壁纸包开始打起。

打包 packing ” 是什么?在 Linux 语境中,“打包”是指制作可以在 Linux 上用软件包管理器来安装、更新和卸载的软件包。

你肯定要问了,什么要打包?举例来说,你肯定有过拍一些照片并且将它们设置为壁纸的经历,对吧。一个个传到计算机上去挺累的。把这些收集起来,打成一个壁纸包,与其他人分享是个不错的选择。顺便,通过打包,也可以对 Debian 的软件包有个大致的了解。

背景介绍

《崩坏 3》,是一个我很喜欢玩的游戏,但它不支持 Linux 平台,所以,望梅止渴的我只好把这些壁纸进行打包,以此纪念和女武神们并肩战斗过的时光。

本文中介绍的打包是给 Debian/Ubuntu 系所用的 deb 包,其他系或独立发行版请按所属发行版的官方手册进行打包工作。

准备工作

先准备如下工具 wgettardh-makedebmakelintian(有一些应该在你 Linux 上已经安装过了):

~ $ sudo apt install wget tar dh-make debmake lintian

先建立打包文件夹:

make $ mkdir -p honkai-impact3-0.1/usr/share/background/honkai-impact3

更换壁纸的时候你应该注意到了,通常壁纸的存放位置都是在 /usr/share/background 目录里的,所以这里建立了相应的多级目录。

你也可以用你自己拍摄的照片来打包,本文所用的演示图片均来自于《崩坏 3》官网,你可以自行下载。

开始打包

然后,退回到上级目录里,将存放壁纸的目录压缩成一个 tar 包:

honkai-impact3-0.1 $ cd ..
make $ tar -cvzf honkai-impact3-0.1.tar.gz honkai-impact3-0.1/usr/share/background/honkai-impact3

压缩包创建好之后,我们还得设置两个变量,这样软件包维护工具就可以正确识别维护者信息了:

make $ cat >> ~/.bashrc <<EOF
DEBEMAIL="bronya_zaychik@st_freya_academy.edu"
DEBFULLNAME="Bronya Zaychik"
export DEBEMAIL DEBFULLNAME
EOF
make $ . ~/.bashrc

此处:

  • DEBEMAIL 写你的邮箱地址
  • DEBFULLNAME 写维护者的名字

初始化

make $ cd honkai-impact3-0.1 
honkai-impact3-0.1 $ dh_make -f ../honkai-impact3-0.1.tar.gz
Type of package: (single, indep, library, python)
[s/i/l/p]?
Maintainer Name     : Bronya Zaychik
Email-Address       : bronya_zaychik@st_freya_academy.edu
Date                : Wed, 02 Feb 2022 07:00:28 +0000
Package Name        : honkai-impact3
Version             : 0.1
License             : blank
Package Type        : library
Are the details correct? [Y/n/q]

dh_make 是个不错的工具,这工具用于初始化压缩包并生成模板文件。下面的 debian 文件夹就是用这个工具生成的。

在初始化完成之后,你会看到如下文件:

honkai-impact3-0.1 $ cd ..
make $ ls -F
honkai-impact3-0.1/
honkai-impact3-0.1.tar.gz
honkai-impact3_0.1.orig.tar.gz

debian 文件夹里却有了很多模板文件,在一阵怒砍之后,只留下如下文件:

make $ ls -F honkai-impact3-0.1/debian/
source/
changelog
control
copyright
rules

其中,changlog 文件是用来记录版本更新内容的变更日志。

例如:

honkai-impact3-0.1 $ cat debian/changelog
honkai-impact3-background (0.1-1) unstable; urgency=medium

  * 2020.8.17 首次打包完成
  * 2022.2.2  重新打包

 -- Bronya Zaychik <bronya_zaychik@st_freya_academy.edu> Wed, 02 Feb 2022 07:20:00 +0000

honkai-impact3-background (0.1-1) unstable; urgency=medium

  * Initial release 

 -- Bronya Zaychik <bronya_zaychik@st_freya_academy.edu> Wed, 02 Feb 2022 07:00:28 +0000

control 文件用来记录壁纸包的版本信息:

honkai-impact3-0.1 $ cat debian/control
Package: honkai-impact3-background
Version: 0.1-1
Architecture: all
Maintainer: Bronya Zaychik <bronya_zaychik@st_freya_academy.edu>
Section: x11
Priority: optional
Homepage: https://gitee.com/PokerFace128/K423_Lab_Soft
Description: This is the game wallpaper of the HokaiImpact3.
 TECH OTAKUS SAVE THE WORLD

说明如下:

  • 第 1-2 行是包名和版本号
  • 第 3 行是可以编译该二进制包的体系结构,通常文本、图像、或解释型语言脚本所生成的二进制包都用 Architecture: all
  • 第 4 行是维护者信息
  • 第 5 行是分类,这里我们选择为 x11,这是不属于其他分类的为 X11 程序
  • 第 6 行是优先级,这个为常规优先级。
  • 第 7 行是维护者的个人主页,GitHub、Gitee,甚至是你的 BiliBili 主页都可以。
  • 第 8 行是对这个软件包的描述
  • 第 9 行建议写点什么上去,这样在用 lintian 检查的时候就不会空了。

最后是 copyright 文件,用来存放版权信息。就是该软件包内文件的版权说明。至于这个示例壁纸包,由于版权属于该游戏出品方,作为演示用途,我这里就没填。

开始打包

只需一个命令,就可轻松打包:

make $ cd honkai-impact3-0.1/
honkai-impact3-0.1 $ dpkg-buildpackage -us -uc

你应该用过 dpkg -i 这条命令,dpkg 工具不只能安装,还能打包和拆包。

啪的一下,一个壁纸包就这样打好了:

honkai-impact3-0.1 $ cd ../
make $ ls -F 
honkai-impact3-0.1/                   
honkai-impact3_0.1-1_amd64.changes  
honkai-impact3_0.1-1.debian.tar.xz  
honkai-impact3_0.1.orig.tar.gz
honkai-impact3_0.1-1_amd64.buildinfo  
honkai-impact3_0.1-1_amd64.deb      
honkai-impact3_0.1-1.dsc            
honkai-impact3-0.1.tar.gz

接下来用 lintian 检查

make $ lintian honkai-impact3_0.1-1_amd64.deb   

E: honkai-impact3-background: copyright-contains-dh_make-todo-boilerplate
E: honkai-impact3-background: helper-templates-in-copyright
W: honkai-impact3-background: copyright-has-url-from-dh_make-boilerplate

这里显示我没填 copyright 文件,这里需要你填入版权信息,像壁纸类的话,通常都是 CC 协议。

打包好之后就像这样:

如果你想了解关于 deb 打包的更多内容,请看如下链接:https://www.debian.org/doc/manuals/maint-guide/index.zh-cn.html

作者注:因读者多次吐槽,文章经过了反复修改。详情请看 GitHub 上的 PR。


作者简介:

PokerFace,一个会空中劈叉的老舰长(睿智清洁工)。


作者:PokerFace 编辑:wxy

本文由贡献者投稿至 Linux 中国公开投稿计划,采用 CC-BY-SA 协议 发布,Linux中国 荣誉推出

使用 setuptools 来向用户交付 Python 代码。

 title=

你花了几周的时间来完善你的代码。你已经对它进行了测试,并把它发送给一些亲近的开发者朋友以保证质量。你已经将所有的源代码发布在 你的个人 Git 服务器 上,并且从一些勇敢的早期使用者收到了一些有用的错误报告。现在你已经准备好将你的 Python 代码提供给全世界。

就在这时你遇到一个问题。你不知道如何交付产品。

将代码交付给它的目标用户是一件大事。这是软件开发的一个完整的分支,是 CI/CD 中的 “D”,但很多人都忘记了,至少到最后才知道。我写过关于 AutotoolsCmake 的文章,但有些语言有自己的方法来帮助你将你的代码提供给用户。对于 Python 来说,向用户提供代码的一个常见方法是使用 setuptools

安装 setuptools

安装和更新 setuptools 的最简单方法是使用 pip

$ sudo python -m pip install --upgrade setuptools

示例库

我创建了一个简单的 Python 库,名为 myhellolib,来作为需要打包的示例代码。这个库接受一个字符串,然后用大写字母打印出这个字符串。

它只有两行代码,但项目结构很重要,所以首先创建目录树:

$ mkdir -p myhellolib.git/myhellolib

为了确认这个项目是一个可导入的库(即 Python “模块”),在代码目录中创建一个空文件 __init__.py,同时创建一个包含代码的文件:

$ touch myhellolib.git/myhellolib/__init__.py
$ touch myhellolib.git/myhellolib/myhellolib.py

myhellolib.py 文件中,输入简单的 Python 代码:

def greeter(s):
    print(s.upper())

这就是写好的库。

测试它

在打包之前,测试一下你的库。创建一个 myhellolib.git/test.py 文件并输入以下代码:

import myhellolib.myhellolib as hello
hello.greeter("Hello Opensource.com.")

运行该脚本:

$ cd myhellolib.git
$ python ./test.py
HELLO OPENSOURCE.COM

它可以工作,所以现在你可以把它打包了。

Setuptools

要用 setuptools 打包一个项目,你必须创建一个 .toml 文件,将 setuptools 作为构建系统。将这段文字放在项目目录下的 myhellolib.toml 文件中。

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

接下来,创建一个名为 setup.py 的文件,包含项目的元数据:

from setuptools import setup

setup(
   name='myhellolib',
   version='0.0.1',
   packages=['myhellolib'],
   install_requires=[
      'requests',
      'importlib; python_version == "3.8"',
   ],
)

不管你信不信,这就是 setuptools 需要的所有设置。你的项目已经可以进行打包。

打包 Python

要创建你的 Python 包,你需要一个构建器。一个常见的工具是 build,你可以用 pip 安装它:

$ python -m pip install build --user

构建你的项目:

$ python -m build

过了一会儿,构建完成了,在你的项目文件夹中出现了一个新的目录,叫做 dist。这个文件夹包含一个 .tar.gz 和一个 .whl 文件。

这是你的第一个 Python 包! 下面是包的内容:

$ tar --list --file dist/myhellolib-0.0.1.tar.gz
myhellolib-0.0.1/
myhellolib-0.0.1/PKG-INFO
myhellolib-0.0.1/myhellolib/
myhellolib-0.0.1/myhellolib/__init__.py
myhellolib-0.0.1/myhellolib/myhellolib.py
myhellolib-0.0.1/myhellolib.egg-info/
myhellolib-0.0.1/myhellolib.egg-info/PKG-INFO
myhellolib-0.0.1/myhellolib.egg-info/SOURCES.txt
myhellolib-0.0.1/myhellolib.egg-info/dependency_links.txt
myhellolib-0.0.1/myhellolib.egg-info/requires.txt
myhellolib-0.0.1/myhellolib.egg-info/top_level.txt
myhellolib-0.0.1/setup.cfg
myhellolib-0.0.1/setup.py

$ unzip -l dist/myhellolib-0.0.1-py3-none-any.whl 
Archive:  dist/myhellolib-0.0.1-py3-none-any.whl
Name
----
myhellolib/__init__.py
myhellolib/myhellolib.py
myhellolib-0.0.1.dist-info/METADATA
myhellolib-0.0.1.dist-info/WHEEL
myhellolib-0.0.1.dist-info/top_level.txt
myhellolib-0.0.1.dist-info/RECORD
-------
6 files

让它可用

现在你知道了打包你的 Python 包是多么容易,你可以使用 Git 钩子、GitLab Web 钩子、Jenkins 或类似的自动化工具来自动完成这个过程。你甚至可以把你的项目上传到 PyPi,这个流行的 Python 模块仓库。一旦它在 PyPi 上,用户就可以用 pip 来安装它,就像你在这篇文章中安装 setuptoolsbuild 一样!

当你坐下来开发一个应用或库时,打包并不是你首先想到的事情,但它是编程的一个重要方面。Python 开发者在程序员如何向世界提供他们的工作方面花了很多心思,没有比 setuptools 更容易的了。试用它,使用它,并继续用 Python 编码!


via: https://opensource.com/article/21/11/packaging-python-setuptools

作者:Seth Kenlon 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解如何使用 dh\_virtualenv 来让你的 Python 应用可作为 .deb 包安装。

在基于 Debian 的操作系统(例如 Debian 或 Elementary OS)上安装 Python 应用的一种方法是使用 dh\_virtualenv 工具。它可以构建一个 .deb 包,在应用之外封装了一个 Python 虚拟环境,并在安装时进行部署。

在本文中,我将以构建一个包含 HTTPie 工具的包为例来解释如何使用它,以便在无需激活虚拟环境的情况下从命令行测试 HTTP API。

使用 dh\_virtualenv 打包

首先,你需要安装 dh_virtualenv 所需的工具。dh_virtualenv文档提供了所有安装选项。在基于 Debian 的系统上,我输入:

apt-get install dh-virtualenv devscripts

尽管不需要 devscripts 包,但它可以简化后续操作。

现在,创建一个目录来保存源码。由于这是一个本地的、非官方的 HTTPie 打包,因此我将其称为 myhttp。接下来,让我们在 myhttp 内创建一些文件,向 Debian 构建系统提供元数据。

首先,创建 debian/control 文件:

Source: myhttp
Section: python
Priority: extra
Maintainer: Jan Doe <[email protected]>
Build-Depends: debhelper (>= 9), python3.7, dh-virtualenv (>= 0.8)
Standards-Version: 3.9.5

Package: myhttp
Architecture: any
Pre-Depends: dpkg (>= 1.16.1), python3.7, ${misc:Pre-Depends}
Depends: ${misc:Depends}
Description: http client
 Useful for doing stuff

那么这些是什么信息呢?正如 Debian 文档指出的:

“第 1–7 行是源码包的控制信息。第 9–13 行是二进制包的控制信息。”

以下是我使用的:

  • Section 的值对于我们来说大多没有意义,但需要存在。它对给引导式 UI 安装程序提供信息是有意义的,但对于这个包来说,没有意义。
  • Priority 对像这样的第三方包的正确值是 extra
  • 强烈建议在 Maintainer 字段中填写正确的联系人信息。但不一定非得是你的个人电子邮件,如果包由团队维护,并且你希望将问题发送到团队的邮件别名,例如 Infrastructure Team <[email protected]>
  • Build-Depends 字段标识你需要 debhelperpythondh-virtualenv 来构建包:包构建过程中将确保这些依赖项在包构建时已安装。
  • Standards-Version 字段主要给人看。它表明你遵循的指南。本指南基于 dh-virtualenv 的官方文档,它是基于 Debian 的 3.9.5 指南。最好一直将源码包和二进制包命名相同。
  • Architecture 字段应为 Any,因为除非虚拟环境可能包含一些特定于体系结构的文件。否则,最好选择该字段为 any
  • 保持 Pre-Depends 列表不变:它是一种非常严格的依赖关系形式,你很少会需要比这里建议的最小依赖更多的依赖项。依赖项通常由构建系统准确计算,因此没有理由手动指定它们。
  • 如果你的包主要用于内部,那么 Description 字段可能只需要最少的信息或者指向公司 wiki 的链接,不然更多的信息会更有用。

然后创建 debian/compat 文件,它主要出于历史目的而存在

$ echo "9" > debian/compat

接下来,创建更新日志以告知包用户自上次发布以来发生了什么变化。最简单的方法是使用 dch --create 创建模板,然后填写值。

填写后,它看起来像:

myhttp (2.0.0-1) stable; urgency=medium

  * Initial release.

 -- Jan Doe <[email protected]>  Fri, 27 Mar 2020 01:09:22 +0000

现在你需要告诉工具安装 HTTPie,但是哪个版本?

创建一个宽松版本的 requirements.in 文件:

httpie

通常,宽松的需求文件将仅包含项目的直接依赖项,并在需要时指定最低版本。不一定总是需要指定最低版本:这些工具通常偏向于将依赖关系转化为“可能的最新版本”。如果你的 Debian 包与一个内部 Python 包相对应,这是内部应用中的一种常见情况,那么宽松的需求文件看起来将很相似:仅包含包名的一行。

然后使用 pip-compile(可通过安装 PyPI 包 pip-tools 获得):

$ pip-compile requirements.in > requirements.txt

这会生成一个严格的依赖文件,名为 requirements.txt

#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile requirements.in
#
certifi==2019.11.28       # via requests
chardet==3.0.4            # via requests
httpie==2.0.0             # via -r requirements.in
idna==2.9                 # via requests
pygments==2.6.1           # via httpie
requests==2.23.0          # via httpie
urllib3==1.25.8           # via requests

最后,写一个 debian/rules 文件来创建包。因为 dh_virtualenv 会处理所有困难的事,因此规则文件很简单:

#!/usr/bin/make -f

%:
        dh $@ --with python-virtualenv --python /usr/bin/python3.7

确保指定 Python 解释器。默认它会使用 /usr/bin/python,这是 Python2,但是你应该使用一个受支持的 Python 版本

完成了,接下来就是构建包:

$ debuild -b -us -uc

这会在父目录生成一个类似 myhttp_2.0.0-1_amd64.deb 的文件。该文件可在任何兼容的系统上安装。

通常,最好在同一平台上构建用于特定平台(例如 Debian 10.0)的 Debian 包。

你可以将此 Debian 包保存在软件仓库中,并使用例如 Ansible 的工具将其安装在所有相关系统上。

总结

给基于 Debian 的系统的打包应用是一个有着多个步骤的过程。使用 dh_virtualenv 将使过程变得简单明了。


via: https://opensource.com/article/20/4/package-python-applications-linux

作者:Moshe Zadka 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

创建 CardBook 软件包、本地 Debian 仓库,并修复错误。

我在 GSoC(LCTT 译注:Google Summer Of Code,一项针对学生进行的开源项目训练营,一般在夏季进行。)的任务中有一项是为用户构建 Thunderbird 扩展 add-ons 。一些非常流行的扩展,比如 Lightning (日历行事历)已经拥有了 deb 包。

另外一个重要的用于管理基于 CardDav 和 vCard 标准的联系人的扩展 Cardbook ,还没有一个 deb 包。

我的导师, Daniel 鼓励我去为它制作一个包,并上传到 mentors.debian.net。因为这样就可以使用 apt-get 来安装,简化了安装流程。这篇博客描述了我是如何从头开始学习为 CardBook 创建一个 Debian 包的。

首先,我是第一次接触打包,我在从源码构建包的基础上进行了大量研究,并检查它的协议是是否与 DFSG 兼容。

我从多个 Debian Wiki 中的指南中进行学习,比如 打包介绍构建一个包,以及一些博客。

我还研究了包含在 Lightning 扩展包的 amd64 文件。

我创建的包可以在这里找到。

Debian Package!

Debian 包

创建一个空的包

我从使用 dh_make 来创建一个 debian 目录开始。

# Empty project folder
$ mkdir -p Debian/cardbook
# create files
$ dh_make\
> --native \
> --single \
> --packagename cardbook_1.0.0 \
> --email [email protected]

一些重要的文件,比如 controlruleschangelogcopyright 等文件被初始化其中。

所创建的文件的完整列表如下:

$ find /debian
debian/
debian/rules
debian/preinst.ex
debian/cardbook-docs.docs
debian/manpage.1.ex
debian/install
debian/source
debian/source/format
debian/cardbook.debhelper.lo
debian/manpage.xml.ex
debian/README.Debian
debian/postrm.ex
debian/prerm.ex
debian/copyright
debian/changelog
debian/manpage.sgml.ex
debian/cardbook.default.ex
debian/README
debian/cardbook.doc-base.EX
debian/README.source
debian/compat
debian/control
debian/debhelper-build-stamp
debian/menu.ex
debian/postinst.ex
debian/cardbook.substvars
debian/files

我了解了 Debian 系统中 Dpkg 包管理器及如何用它安装、删除和管理包。

我使用 dpkg 命令创建了一个空的包。这个命令创建一个空的包文件以及四个名为 .changes.deb.dsc.tar.gz 的文件。

  • .dsc 文件包含了所发生的修改和签名
  • .deb 文件是用于安装的主要包文件。
  • .tar.gz (tarball)包含了源代码

这个过程也在 /usr/share 目录下创建了 READMEchangelog 文件。它们包含了关于这个包的基本信息比如描述、作者、版本。

我安装这个包,并检查这个包安装的内容。我的新包中包含了版本、架构和描述。

$ dpkg -L cardbook
/usr
/usr/share
/usr/share/doc
/usr/share/doc/cardbook
/usr/share/doc/cardbook/README.Debian
/usr/share/doc/cardbook/changelog.gz
/usr/share/doc/cardbook/copyright

包含 CardBook 源代码

在成功的创建了一个空包以后,我在包中添加了实际的 CardBook 扩展文件。 CardBook 的源代码托管在 Gitlab 上。我将所有的源码文件包含在另外一个目录,并告诉打包命令哪些文件需要包含在这个包中。

我使用 vi 编辑器创建一个 debian/install 文件并列举了需要被安装的文件。在这个过程中,我花费了一些时间去学习基于 Linux 终端的文本编辑器,比如 vi 。这让我熟悉如何在 vi 中编辑、创建文件和快捷方式。

当这些完成后,我在变更日志中更新了包的版本并记录了我所做的改变。

$ dpkg -l | grep cardbook
ii cardbook 1.1.0 amd64 Thunderbird add-on for address book

Changelog

更新完包的变更日志

在重新构建完成后,重要的依赖和描述信息可以被加入到包中。 Debian 的 control 文件可以用来添加额外的必须项目和依赖。

本地 Debian 仓库

在不创建本地存储库的情况下,CardBook 可以使用如下的命令来安装:

$ sudo dpkg -i cardbook_1.1.0.deb

为了实际测试包的安装,我决定构建一个本地 Debian 存储库。没有它,apt-get 命令将无法定位包,因为它没有在 Debian 的包软件列表中。

为了配置本地 Debian 存储库,我复制我的包 (.deb)为放在 /tmp 目录中的 Packages.gz 文件。

Packages-gz

本地 Debian 仓库

为了使它工作,我了解了 apt 的配置和它查找文件的路径。

我研究了一种在 apt-config 中添加文件位置的方法。最后,我通过在 APT 中添加 *.list 文件来添加包的路径,并使用 apt-cache 更新APT缓存来完成我的任务。

因此,最新的 CardBook 版本可以成功的通过 apt-get install cardbook 来安装了。

Package installation!

使用 apt-get 安装 CardBook

修复打包错误和 Bugs

我的导师 Daniel 在这个过程中帮了我很多忙,并指导我如何进一步进行打包。他告诉我使用 Lintian 来修复打包过程中出现的常见错误和最终使用 dput 来上传 CardBook 包。

Lintian 是一个用于发现策略问题和 Bug 的包检查器。它是 Debian 维护者们在上传包之前广泛使用的自动化检查 Debian 策略的工具。

我上传了该软件包的第二个更新版本到 Debian 目录中的 Salsa 仓库 的一个独立分支中。

我从 Debian backports 上安装 Lintian 并学习在一个包上用它来修复错误。我研究了它用在其错误信息中的缩写,和如何查看 Lintian 命令返回的详细内容。

$ lintian -i -I --show-overrides cardbook_1.2.0.changes

最初,在 .changes 文件上运行命令时,我惊讶地看到显示出来了大量错误、警告和注释!

 title=

在包上运行 Lintian 时看到的大量报错

Lintian error1!

详细的 Lintian 报错

Lintian error2!

详细的 Lintian 报错 (2) 以及更多

我花了几天时间修复与 Debian 包策略违例相关的一些错误。为了消除一个简单的错误,我必须仔细研究每一项策略和 Debian 的规则。为此,我参考了 Debian 策略手册 以及 Debian 开发者参考

我仍然在努力使它变得完美无暇,并希望很快可以将它上传到 mentors.debian.net!

如果 Debian 社区中使用 Thunderbird 的人可以帮助修复这些报错就太感谢了。


via: http://minkush.me/cardbook-debian-package/

作者:Minkush Jain 选题:lujun9972 译者:Bestony 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

过了这个夏天,我把我的桌面环境迁移到了 i3,这是一个瓦片式窗口管理器。当初,切换到 i3 是一个挑战,因为我必须去处理许多以前 GNOME 帮我处理的事情。其中一件事情就是改变屏幕亮度。 xbacklight 这个在笔记本电脑上改变背光亮度的标准方法,它在我的硬件上不工作了。

最近,我发现一个改变背光亮度的工具 brightlight。我决定去试一下它,它工作在 root 权限下。但是,我发现 brightligh 在 Fedora 下没有 RPM 包。我决定,是在 Fedora 下尝试创建一个包的时候了,并且可以学习怎么去创建一个 RPM 包。

在这篇文章中,我将分享以下的内容:

  • 创建 RPM SPEC 文件
  • 在 Koji 和 Copr 中构建包
  • 使用调试包处理一个问题
  • 提交这个包到 Fedora 包集合中

前提条件

在 Fedora 上,我安装了包构建过程中所有步骤涉及到的包。

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

创建 RPM SPEC 文件

创建 RPM 包的第一步是去创建 SPEC 文件。这些规范,或者是指令,它告诉 RPM 怎么去构建包。这是告诉 RPM 从包的源代码中创建一个二进制文件。创建 SPEC 文件看上去是整个包处理过程中最难的一部分,并且它的难度取决于项目。

对我而言,幸运的是,brightlight 是一个用 C 写的简单应用程序。维护人员用一个 Makefile 使创建二进制应用程序变得很容易。构建它只是在仓库中简单运行 make 的问题。因此,我现在可以用一个简单的项目去学习 RPM 打包。

查找文档

谷歌搜索 “how to create an RPM package” 有很多结果。我开始使用的是 IBM 的文档。然而,我发现它理解起来非常困难,不知所云(虽然十分详细,它可能适用于复杂的 app)。我也在 Fedora 维基上找到了 创建包 的介绍。这个文档在构建和处理上解释的非常好,但是,我一直困惑于 “怎么去开始呢?”

最终,我找到了 RPM 打包指南,它是大神 Adam Miller 写的。这些介绍非常有帮助,并且包含了三个优秀的示例,它们分别是用 Bash、C 和 Python 编写的程序。这个指南帮我很容易地理解了怎么去构建一个 RPM SPEC,并且,更重要的是,解释了怎么把这些片断拼到一起。

有了这些之后,我可以去写 brightlight 程序的我的 第一个 SPEC 文件 了。因为它是很简单的,SPEC 很短也很容易理解。我有了 SPEC 文件之后,我发现其中有一些错误。处理掉一些错误之后,我创建了源 RPM (SRPM) 和二进制 RPM,然后,我解决了出现的每个问题。

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SPECS/brightlight-5-1.fc26.x86_64.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

现在,我有了一个可用的 RPM,可以发送到 Fedora 仓库了。

在 Copr 和 Koji 中构建

接下来,我读了该 指南 中关于怎么成为一个 Fedora 打包者。在提交之前,他们鼓励打包者通过在在 Koji 中托管、并在 Copr 中构建项目来测试要提交的包。

使用 Copr

首先,我为 brightlight 创建了一个 Copr 仓库Copr 是在 Fedora 的基础设施中的一个服务,它构建你的包,并且为你任意选择的 Fedora 或 EPEL 版本创建一个定制仓库。它对于快速托管你的 RPM 包,并与其它人去分享是非常方便的。你不需要特别操心如何去托管一个 Copr 仓库。

我从 Web 界面创建了我的 Copr 项目,但是,你也可以使用 copr-cli 工具。在 Fedora 开发者网站上有一个 非常优秀的指南。在该网站上创建了我的仓库之后,我使用这个命令构建了我的包。

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

我的包在 Corp 上成功构建,并且,我可以很容易地在我的 Fedora 系统上成功安装它。

使用 Koji

任何人都可以使用 Koji 在多种架构和 Fedora 或 CentOS/RHEL 版本上测试他们的包。在 Koji 中测试,你必须有一个源 RPM。我希望 brightlight 包在 Fedora 所有的版本中都支持,因此,我运行如下的命令:

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

它花费了一些时间,但是,Koji 构建了所有的包。我的包可以很完美地运行在 Fedora 25 和 26 中,但是 Fedora 27 失败了。 Koji 模拟构建可以使我走在正确的路线上,并且确保我的包构建成功。

问题:Fedora 27 构建失败!

现在,我已经知道我的 Fedora 27 上的包在 Koji 上构建失败了。但是,为什么呢?我发现在 Fedora 27 上有两个相关的变化。

这些变化意味着 RPM 包必须使用一个 debuginfo 包去构建。这有助于排错或调试一个应用程序。在我的案例中,这并不是关键的或者很必要的,但是,我需要去构建一个。

感谢 Igor Gnatenko,他帮我理解了为什么我在 Fedora 27 上构建包时需要去将这些增加到我的包的 SPEC 中。在 %make_build 宏指令之前,我增加了这些行。

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

我构建了一个新的 SRPM 并且提交它到 Koji 去在 Fedora 27 上构建。成功了,它构建成功了!

提交这个包

现在,我在 Fedora 25 到 27 上成功校验了我的包,是时候为 Fedora 打包了。第一步是提交这个包,为了请求一个包评估,要在 Red Hat Bugzilla 创建一个新 bug。我为 brightlight 创建了一个工单。因为这是我的第一个包,我明确标注它 “这是我的第一个包”,并且我寻找一个发起人。在工单中,我链接 SPEC 和 SRPM 文件到我的 Git 仓库中。

进入 dist-git

Igor Gnatenko 发起我进入 Fedora 打包者群组,并且在我的包上留下反馈。我学习了一些其它的关于 C 应用程序打包的特定的知识。在他响应我之后,我可以在 dist-git 上申请一个仓库,Fedora 的 RPM 包集合仓库为所有的 Fedora 版本保存了 SPEC 文件。

一个很方便的 Python 工具使得这一部分很容易。fedrepo-req 是一个用于创建一个新的 dist-git 仓库的请求的工具。我用这个命令提交我的请求。

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

它为我在 fedora-scm-requests 仓库创建了一个新的工单。这是一个我是管理员的 创建的仓库。现在,我可以开始干了!

My first RPM in Fedora dist-git – woohoo!

与 dist-git 一起工作

接下来,fedpkg 是用于和 dist-git 仓库进行交互的工具。我改变当前目录到我的 git 工作目录,然后运行这个命令。

fedpkg clone brightlight

fedpkg 从 dist-git 克隆了我的包的仓库。对于这个仅有的第一个分支,你需要去导入 SRPM。

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg 导入你的包的 SRPM 到这个仓库中,然后设置源为你的 Git 仓库。这一步对于使用 fedpkg 是很重要的,因为它用一个 Fedora 友好的方去帮助规范这个仓库(与手动添加文件相比)。一旦你导入了 SRPM,推送这个改变到 dist-git 仓库。

git commit -m "Initial import (#1505026)."
git push

构建包

自从你推送第一个包导入到你的 dist-git 仓库中,你已经准备好了为你的项目做一次真实的 Koji 构建。要构建你的项目,运行这个命令。

fedpkg build

它会在 Koji 中为 Rawhide 构建你的包,这是 Fedora 中的非版本控制的分支。在你为其它分支构建之前,你必须在 Rawhide 分支上构建成功。如果一切构建成功,你现在可以为你的项目的其它分支发送请求了。

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

关于构建其它分支的注意事项

一旦你最初导入了 SRPM,如果你选择去创建其它分支,记得合并你的主分支到它们。例如,如果你后面为 Fedora 27 请求一个分支,你将需要去使用这些命令。

fedpkg switch-branch f27
git merge master
git push
fedpkg build

提交更新到 Bodhi

这个过程的最后一步是,把你的新包作为一个更新包提交到 Bodhi 中。当你初次提交你的更新包时,它将去测试这个仓库。任何人都可以测试你的包并且增加 karma 到该更新中。如果你的更新接收了 3 个以上的投票(或者像 Bodhi 称它为 karma),你的包将自动被推送到稳定仓库。否则,一周之后,推送到测试仓库中。

要提交你的更新到 Bodhi,你仅需要一个命令。

fedpkg update

它为你的包用一个不同的配置选项打开一个 Vim 窗口。一般情况下,你仅需要去指定一个 类型(比如,newpackage)和一个你的包评估的票据 ID。对于更深入的讲解,在 Fedora 维基上有一篇更新的指南

在保存和退出这个文件后,fedpkg 会把你的包以一个更新包提交到 Bodhi,最后,同步到 Fedora 测试仓库。我也可以用这个命令去安装我的包。

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

稳定仓库

最近提交了我的包到 Fedora 26 稳定仓库,并且不久将进入 Fedora 25Fedora 27 稳定仓库。感谢帮助我完成我的第一个包的每个人。我期待有更多的机会为发行版添加包。


via: https://blog.justinwflory.com/2017/11/first-rpm-package-fedora/

作者:JUSTIN W. FLORY 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出