IntroductionStarting from this article, as the author began researching infrastructure software in 2025, using large projects like Ceph as examples, I will document the process from Linux packaging to Ceph source code analysis, code upgrades, modifications, and learning algorithm features. Since directly examining the project is the fastest method, I do not intend to provide a detailed introduction to C/C++ as found online, but rather base it directly on the project.Packaging Tools in the Ceph DirectoryThe cephadm tool was completely unusable in production in version 17, so I excluded it. The deb packaging for Ceph does not require looking at the README.md file in its root directory; all packaging definition files are located in its debian directory. I mainly modified the rules, changelog, and control files.Main Points about the Rules File (not recording the meaning of each field)The rules file is equivalent to a makefile. In it, I defined the following to reduce Ceph’s compilation time and eliminate unnecessary binary deb packages:
# tests not build
extraopts += -DWITH_TESTS=OFF
# rgw cannot compile
extraopts += -DWITH_RADOSGW=OFF
extraopts += -DWITH_RADOSGW_BEAST_OPENSSL=OFF
extraopts += -DWITH_RADOSGW_AMQP_ENDPOINT=OFF
extraopts += -DWITH_RADOSGW_KAFKA_ENDPOINT=OFF
extraopts += -DWITH_RADOSGW_LUA_PACKAGES=OFF
extraopts += -DWITH_RADOSGW_DBSTORE=OFF
extraopts += -DWITH_RADOSGW_SELECT_PARQUET=OFF
# product env user Release, else use RelWithDebInfo
extraopts += -DCMAKE_BUILD_TYPE=Release
extraopts += -DWITH_SYSTEM_UTF8PROC=ON
extraopts += -DWITH_OCF=ON -DWITH_LTTNG=ON
extraopts += -DWITH_MGR_DASHBOARD_FRONTEND=OFF
extraopts += -DWITH_PYTHON3=3
extraopts += -DWITH_CEPHFS_JAVA=OFF
extraopts += -DWITH_CEPHFS_SHELL=ON
extraopts += -DWITH_SYSTEMD=ON -DCEPH_SYSTEMD_ENV_DIR=/etc/default
extraopts += -DWITH_GRAFANA=OFF
Since we primarily focus on file systems, and it seems there are some issues with the Ceph file system (we are not a company specialized in storage), we mainly removed RGW, TESTS, and DEBUG packages.Then, use the following command to build only the binary package; you can also add the -nc parameter to avoid cleaning build artifacts:
dpkg-buildpackage -us -uc -b
To avoid cleaning build artifacts, you can also add the following line in the rules file:
override_dh_clean: true
Main Points about the Changelog FileThis mainly involves the iteration of the binary package version. I defined the binary package version at the top of the file, and the compiled binary package is named xxx-version_number.deb, approximately like this.Main Points about the Control FileThis file defines various package names and dependencies.
Package: superstorage-common
Architecture: linux-any
Depends: librbd1 (= ${binary:Version}),
python3-superstoragefs (= ${binary:Version}),
python3-superstorage-argparse (= ${binary:Version}),
python3-superstorage-common (= ${binary:Version}),
python3-prettytable,
python3-rados (= ${binary:Version}),
python3-rbd (= ${binary:Version}),
# python3-rgw (= ${binary:Version}),
${misc:Depends},
${python:Depends},
${shlibs:Depends},
Conflicts: superstorage-client-tools,
Replaces: superstorage (<< 0.7.1-1),
superstorage-client-tools,
superstorage-fs-common (<< 0.7.1-1),
# superstorage-test (<< 9.0.3-1646),
librbd1 (<< 0.7.1-1),
python-superstorage (<< 0.7.1-1),
# radosgw (<< 12.0.3)
Breaks: superstorage (<< 0.7.1-1),
superstorage-fs-common (<< 0.7.1-1),
# superstorage-test (<< 9.0.3-1646),
librbd1 (<< 0.7.1-1),
python-superstorage (<< 0.7.1-1),
# radosgw (<< 12.0.3)
Suggests: superstorage-base (= ${binary:Version}),
superstorage-mds (= ${binary:Version}),
Description: common utilities to mount and interact with a superstorage storage cluster
superstorage is a massively scalable, open-source, distributed storage system that runs on commodity hardware and delivers object, block and file system storage. This is a collection of common tools that allow one to interact with and administer a superstorage cluster.
The above fields are the most typical methods for defining code packages. The Depends field defines the dependencies of this package, showing the specific version numbers it relies on.Therefore, when developing infrastructure software, it is essential to strictly control the operating system version and kernel version, avoiding arbitrary apt updates that could cause system-provided software packages to upgrade.About the .install, .postinst, and .postrm files in the debian directory
-rw-r--r-- 1 1111 users 46 Oct 25 2023 superstorageadm.install
-rw-r--r-- 1 1111 users 1867 Oct 25 2023 superstorageadm.postinst
-rw-r--r-- 1 1111 users 987 Oct 25 2023 superstorageadm.postrm
Here, based on the package name, we can define the .install installation file, the postinst file for pre-installation actions, and the postrm file for post-uninstallation actions.