Checkinstall生成的.deb包为何不适用于分发？如何适配多服务器部署？

Great question—this is a super common pitfall when you're first setting up internal package repos with Checkinstall. Let's break this down clearly.

Why Checkinstall Packages Fail for Distribution #

Checkinstall is built as a quick way to wrap locally compiled software into a package for your own system, not for sharing across multiple machines. Here are the key issues that make it unsuitable for distribution:

• Rough Dependency Handling: Checkinstall only scans your current system's installed libraries to guess dependencies. It can't tell the difference between build-time dependencies (like libfoo-dev) and runtime dependencies (like libfoo), so your package might miss critical runtime libraries that other servers don't have pre-installed.
• Hardcoded System-Specific Values: Local builds often embed paths from your build machine (like temporary directories), user environment variables, or even kernel/architecture-specific flags. These will break on servers with different setups.
• Non-Standard Package Structure: Debian packages follow strict FHS (Filesystem Hierarchy Standard) rules (e.g., binaries in /usr/bin, libs in /usr/lib, configs in /etc). Checkinstall defaults to dumping files into /usr/local, which isn't standard, and may set incorrect file permissions or ownership.
• Unclean Build Residue: Checkinstall doesn't automatically clean up temporary build files, debug symbols, or source code scraps. This bloats your package and can introduce security risks if sensitive files get included accidentally.
• Incomplete Metadata: Debian packages require detailed metadata (maintainer info, versioning, section, description) for proper repo management. Checkinstall generates minimal, generic metadata that makes it hard to track packages or resolve conflicts.
• No Multi-Architecture Support: Packages built with Checkinstall are tied to the architecture of your build machine. You can't use an x86_64-built package on ARM servers, and there's no easy way to cross-compile.

How to Adjust Checkinstall Packages for Distribution #

If you want to stick with Checkinstall as a starting point, you can fix these issues by manually refining the package before distributing it:

1. Fix Dependency Declarations

   • After running Checkinstall, it generates a temporary debian/control file. Open this file and manually add correct Depends, Recommends, and Suggests fields based on the software's actual runtime needs.
   • Use the dpkg-shlibdeps tool to auto-scan your binary files for required shared libraries:

     dpkg-shlibdeps -O path/to/your/binary >> debian/control
     

   • Double-check that build-time dependencies (like -dev packages) aren't listed in runtime dependencies.

2. Remove Hardcoded Values & Standardize Paths

   • Before compiling, run ./configure with explicit standard paths to avoid /usr/local:

     ./configure --prefix=/usr --sysconfdir=/etc
     

   • Use the strings command to scan binaries for hardcoded paths:

     strings path/to/your/binary | grep /your/build/path
     

   • If you find problematic paths, recompile with adjusted configure flags or patch the source code.

3. Enforce FHS-Compliant Structure

   • Move files from non-standard locations (like /usr/local/bin) to their FHS-compliant counterparts (e.g., /usr/bin). You can do this by editing the file list in Checkinstall's prompt, or manually adjusting the debian/install file.
   • Set correct permissions: ensure binaries are executable (chmod 755), config files are readable by all (chmod 644), and ownership is set to root:root.

4. Clean Up Build Residue

   • Before running Checkinstall, run make clean or make distclean to remove temporary build files.
   • Strip debug symbols from binaries to reduce package size:

     strip path/to/your/binary
     

   • Avoid including source code, build logs, or temporary directories in the package.

5. 完善 Metadata

   • Edit debian/control to fill in:
     • Maintainer: Your team's contact (e.g., Your Team <team@yourcompany.com>)
     • Version: Use semantic versioning with a Debian revision (e.g., 1.2.3-1)
     • Section: The appropriate category (e.g., utils, net, web)
     • Description: A clear, detailed explanation of what the package does
   • Add a debian/changelog file to track version changes (use dch --create to generate a template).

6. Test & Validate

   • Use the lintian tool to check for Debian packaging compliance:

     lintian your-package.deb
     

   • Fix all warnings and errors it reports—these are often signs of issues that will break on other servers.
   • Test installing the package on a clean server (matching your target environment) to ensure dependencies are met, paths work, and the software runs correctly.

7. Add Post-Install/Pre-Removal Scripts (If Needed)

   • For services or software that requires setup, create debian/postinst (runs after installation) or debian/prerm (runs before removal) scripts. For example, to start a systemd service after install:

     #!/bin/sh
     systemctl enable --now your-service.service
     

   • Make sure these scripts are executable (chmod 755).

内容的提问来源于stack exchange，提问作者Ilya