For some things, I just roll my eyes, remain silent, and think, “What the hell are you talking about? I can’t understand!”.
In my mind, Linux package management has always been a highlight.
With just one set of commands, you can set up a complete development environment and get a usable web system. How wonderful is that?
Nightmare? That’s just being unaware of the blessings!
Many people do not know how difficult it is for a “package” to enter the “mainstream”.
In Debian, if you want your package to enter Debian, you need to read the “Debian Policy Manual for Package Development and Maintenance”. Only by meeting its requirements can you possibly enter the Debian software repository.
As for what this manual contains, let me extract a few sections for everyone to feel:
-Excerpt Start-
2.1.2 Technical Preparation for Contributors
To become a contributor to the Debian project, you first need to have certain technical skills, including:
Proficient use of version control systems, such as Git.
Familiarity with Debian’s package management system and how to create and maintain software packages.
Good programming practices, including control over code quality and adherence to Debian’s programming standards.
Ability to write high-quality documentation to help users better understand and use the packages.
Additionally, contributors should be familiar with Debian’s communication channels, such as mailing lists and IRC channels, to effectively participate in community communication and collaboration.
2.2 Technical Specifications and Standards
To ensure the quality and consistency of software packages, the Debian project has established a series of technical policies and standards that all contributors must adhere to.
2.2.1 Debian’s Technical Policies
The technical policies cover expectations for software packages, including:
Package building and maintenance should comply with Debian’s free software guidelines.
All packages must use Debian’s standard tools and processes for packaging.
Software packages must meet Debian’s release requirements, including license compatibility.
Packages should follow Debian’s naming conventions and provide clear maintenance and usage documentation.
Furthermore, the technical policies also include guidelines on how to handle bugs and security issues in packages.
2.2.2 Code Quality and Contribution Standards
Code quality is another aspect that the Debian project values. Contributed code must:
Have appropriate test cases to ensure the functionality and reliability of the package.
Be checked for code quality using static code analysis and checking tools, such as linters.
Include detailed change logs and commit messages for easier future maintenance and tracking.
Additionally, the project encourages contributors to submit patches and conduct code reviews to continuously improve the packages.
2.3 Basic Responsibilities of Maintainers
Maintainers play a key role in the Debian community; they are responsible not only for maintaining packages but also for interacting and communicating well with community members.
2.3.1 Package Maintenance Workflow
During the maintenance of packages, maintainers need to follow these processes:
Monitor mailing lists and upstream sources: Maintainers should regularly check relevant mailing lists and upstream source code repositories for information on new version releases and security announcements.
Regularly update packages: Based on upstream updates, synchronize package updates, including new features, bug fixes, and security updates.
Handle bug reports: Actively respond to user feedback and propose solutions for bugs in the packages.
Quality assurance: Before releasing a new version, conduct thorough testing to ensure the stability and compatibility of the new version.
Release new versions: Release new versions of packages according to Debian’s release standards.
2.3.2 Community Interaction and Communication
Interaction with the Debian community is equally important; maintainers should:
Actively participate in mailing list discussions, providing answers and suggestions on package-related issues.
Respond promptly to questions in IRC channels, providing real-time assistance.
Write and update documentation for their packages to ensure new users can easily get started.
Through effective communication and interaction, maintainers can not only improve the quality of packages but also enhance collaboration and trust among community members.
-Excerpt End-
From the above document, we can see a few points: to become a Debian package contributor, one must:
1. Write good code
2. Provide clear documentation that beginners can understand
3. Package according to Debian’s standard format
4. Pay attention to upstream and downstream software situations, updating security issues in a timely manner
5. Keep communication channels like IRC open
Based on these five requirements, the standards are indeed not low.
Even if the actual execution is reduced by 50%, it is still reasonable.
Moreover, Debian also offers three release versions: “stable”, “testing”, and “unstable”. Entering the “stable” version, which is the most stable, often takes 1-2 years.
Although Debian is criticized for aging software packages, the software that has undergone extensive testing is indeed more stable.
This is the situation with Debian.
Red Hat, as an “enterprise-level” Linux system, also has high requirements.
Fedora, as the latest software testing release, goes straight to it.
Only Red Hat can manage to create a separate release as a “test”.
It doesn’t end there; Red Hat has also placed CentOS in front of RHEL, creating a CentOS Stream as a second wall for further testing.
Finally, it reaches RHEL.
Fedora > CentOS Stream > RHEL
With such a level of testing, who else can do it?
There was once a Red Hat system that ran for 20 years without downtime, becoming a legend!
In this context, if someone says “package management has become a nightmare”, there is only one reason – they did things outside the package management system but expect the packages to take the blame.
If a software requires the glibc1.1 library to run, can it work on a system with glibc2?
Linux only guarantees basic compatibility at the “source code” level; wanting it to be like Windows is impossible.
In this article, I mentioned this issue:
What is taken for granted on Windows is often very difficult on Linux?
Here, I want to throw out a viewpoint – the Linux kernel is open source, but Linux distributions are quite closed; it is a complete system.
Within a Linux distribution, it is best to follow its logic.
Because although it is a Linux, it is also a great steward of the computer – the operating system, which has unlimited control over the hard disk and memory, ensuring that files are read and written correctly, various programs get the resources they need, and use CPU and memory more efficiently to meet your needs.
If you don’t let it manage, and you set up your own system, can it work?
In this case, the system you set up becomes the nightmare of the system and the nightmare of the computer.
Not being able to run is a minor issue; a crash can happen in an instant.
This is the truth.
I am Mingyue,
an internet storyteller!
