- Q: What can be done when the dpkg lock is held?
- Q: What are the filesystem requirements by dpkg?
- Q: Why is dpkg so slow when using new filesystems such as btrfs or ext4?
- Q: Why does ''dpkg --set-selections'' not record selections for unknown packages?
- Q: What is the latest dpkg version on each Debian release?
- Behavior Questions
- Feature Request Questions
Q: What can be done when the dpkg lock is held?
A: This means another instance of dpkg or a frontend is running, so the correct solutions are to:
- let the other process end its execution,
- find the frontend and quit it, or
- kill any such frozen processes.
Removing the dpkg lock is not a correct solution, as dpkg uses region locking on an existing file. The presence of the file does not mean that the lock is currently being held, and removing it can most probably cause dpkg database corruption.
Q: What are the filesystem requirements by dpkg?
A: The filesystems are expected to have POSIX semantics.
dpkg expects to operate on filesystems that support at least:
returning the symlink length in stat(2) st_size,
file-region locking (fcntl(2) with F_SETLK),
- replacing files currently open (and being executed).
As such filesystems like FAT32 or AFS are not supported for dpkg managed content.
If you are installing on a NFS root, and locking does not work, make sure rpc.lockd (or its equivalent) is running.
If you need a FAT32 partition to boot with EFI for example, then you should use something like /boot/efi/ to mount the FAT32 partition there, which will not be managed by dpkg, and use kernel postinst hooks to copy any required files, in a similar way as would be done to create an initramfs.
Q: Why is dpkg so slow when using new filesystems such as btrfs or ext4?
A: To guarantee that the filesystem data is always consistent and safe, dpkg performs fsync(2)s on its database and files unpacked from packages. Newer filesystems (like btrfs or ext4) that implement delayed allocation do require those fsync(2)s as they trade data safety for performance, and expect programs to performs those fsync(2)s, but at the same time they have shown very poor performance on the behavior they require from all applications, or they might end up producing zero-length files on system crashes or abrupt shutdowns.
Here's a list of available solutions and workarounds you might consider using:
- For ext4, use instead the "nodelalloc" mount option, which should fix both the performance degradation and the data safety issues, and not for just dpkg, but for any application in the system.
- Switch to another filesystem entirely that does not force choosing between acceptable performance and data safety.
Use the dpkg --force-unsafe-io option, which avoids those fsync(2)s on filesystem files, but still performs them on the dpkg database. This option might improve performance at the cost of losing data, use with care.
If --force-unsafe-io is still not good enough, you might consider using (in addition or instead) eatmydata, which will get rid of any fsync(2) at all. You might want to have backups around, though.
Q: Why does ''dpkg --set-selections'' not record selections for unknown packages?
A: Due to multiarch, the dpkg command-line interface dealing with package name input needed to change. To avoid the possibility for dpkg to be unable to refer to packages in its own database, selections for unknown packages are not recorded any longer. So the available database needs to be up-to-date before any selection is set, this also gives the benefit of warning on unknown packages so that the user knows what will be missing. There are several ways to update the available database, depending on the package manager frontend being used, any single one of them will be enough:
apt-based (apt, aptitude, synaptic, etc):
(from apt, with dpkg 1.17.7 and later)
apt-cache dumpavail | dpkg --merge-avail
(from apt, with dpkg 1.17.6 and earlier)
avail=`mktemp` apt-cache dumpavail >"$avail" dpkg --merge-avail "$avail" rm "$avail"
(from dselect, using the apt access method)
(from dselect, using any of the builtin access methods)
Q: What is the latest dpkg version on each Debian release?
A: Starting with Debian 4.0, each Debian release starts a new dpkg minor version cycle. Take into account that these are not the versions initially shipped on each of those releases, as subsequent updates for security or serious bugs have possibly been issued. This is the current list:
Q: Will dpkg replace a symlink with a directory or vice versa?
A: No. As dpkg does not currently track file metadata, it does not know if a symlink or directory was switched by a previous package or by the sysadmin. As part of the dpkg credo, preserving human configuration is of utmost importance, and this kind of change has always been considered as so.
As of now, this should be handled by the package maintainer scripts (possibly with aid from dpkg-maintscript-helper), failing to do so should be considered a serious bug.
Q: Can dpkg be told to avoid invoking a harmful prerm from an installed package on upgrade?
A: No. There's currently no way to tell dpkg not to execute such prerm maintainer scripts, but there is an extreme workaround available.
Only if the prerm is doing something really harmful, not just for simple failures or actions that can be easily reverted by the new postinst, then the only available way is to make a new, independent package that replaces the broken package's prerm, and then make the new version of the broken package pre-depend on it. This requires modifying the dpkg database, and as such is strongly discouraged, and should only be used as a last resort measure. Proposed by Joey Hess.
Q: Can dpkg handle volatile files?
A: Partially. dpkg does not have full native support (yet) for volatile files (those that might change during the life of a specific installed version), but there are some workarounds that can be used for now:
Ship an initial file (possibly empty) on the .deb that gets modified on the filesystem later on, but this will make the file hashes not match with stuff like the new «dpkg --verify» or debsums. While this might be the most convenient option, it's also possibly the most wrong one. This should never be used for volatile files such as logs or caches or the like.
- Do not ship the file in the .deb, and generate it at installation time, run-time or whenever, but the maintainer scripts will need to deal with the removal manually. This is the more correct but slightly more cumbersome option.
- If the volatile file changes are due to external forces, like updates from a website or similar, then it might be best to automatically generate a new package every time these files change, and ship them normally in a package from a repository.
In the future, dpkg might acquire the ability to register external files, and one kind of such files could be changing files, so dpkg would take care of removing them, and would not store file hashes for these, etc.
Feature Request Questions
Q: Can we add support for new compressors for .dsc packages?
A: Adding more compression formats support to dpkg-source has some benefits as it avoids having to repack the original source tarball, and in this way checksums or upstream signatures are preserved, it might also improve compression ratio compared to previous supported compressions.
But then, the costs of adding support for an additional compression format are quite high, to the point that those benefits seem small compared to them. The costs are (at least): increase in the build-essential set; the new compression becomes part of the source format forever, as it can never be taken back as old Debian packages or 3rd-party packages in the wild might be using that format; it's another (uncommon) package required on non-Debian-based systems to be able to handle those source packages.
With the above in mind, the new compression format should really be very widely used to distribute upstream source and it should improve compression ratio compared to previously supported formats to start considering adding it.
Q: Can we add support for new compressors for .deb packages?
A: Adding more compression formats support to dpkg-deb can be considered, as long as it provides significant advantages to previously supported compression formats.
But then, the costs of adding support for an additional compression format are quite high, to the point that those benefits seem small compared to them. The costs are (at least): increase in the pseudo-essential set; the new compression becomes part of the binary format forever, as it can never be taken back as old Debian binary packages or 3rd-party packages in the wild might be using that format; it's another (uncommon) package required on non-Debian-based systems to be able to handle those binary packages; and all binary package parsers need to be updated to support the new format (see Teams/Dpkg/DebSupport).
With the above in mind, the new compression format should have portable implementations, should be somewhat common, and it should improve compression ratio compared to previously supported formats to start considering adding it.
Q: Can we add support for new default build flags to dpkg-buildflags?
A: Certainly. But before considering adding any flag to the default, the following things would need to be considered:
- The flag should not involve any warning about style issues (those are subjective and dependant on upstream coding standards).
- A test rebuild of the whole archive w/ and w/o the flags, and a comparison to see how much difference is there in the amount built.
- For non-warning flags, a comparison of the build logs to see the memory and build time difference if these might seem relevant (sbuild should provide those).
- Once these are done, and if it still seems worth it, a discussion started in debian-devel proposing the change, asking if there's other known issues, concerns, etc.
Q. Can we add support for a new dpkg architecture?
A: Sure. These are the current requirements for a new dpkg architecture:
It should have an official GNU triplet in the GNU config project.
It should not require the machine manufacturer (or vendor) part of the GNU triplet to be used to distinguish the ABI, nor it should expose it as unknown in the GNU triplet names nor internally in the Debian tuple.
- It should not have the same (full) ABI as any existing dpkg architecture.
- The mapping between a GNU triplet and a dpkg architecture should be 1:1 (i.e. bijective).
- The dpkg architecture name should have been vetted by the current architecture porting team and/or the dpkg maintainers.
- The dpkg architecture name should try to use a pattern similar to an already existing and related architecture (although there's existing exceptions to this due to historical reasons, but those should not be used as precedent!).
- The bits size gets appended to the base architecture cpu name (for example sparc and sparc64).
The endianness gets appended to the base architecture cpu name. The suffixes are eb for big-endian and el for little-endian. If the architecture is not capable of operating with either endianness, then there's no need to suffix it. If one of the endianness is the prevalent one and the other sees marginal use, then the prevalent one can obviate the endianness suffix.
- The dpkg architecture name has the following additional characteristics:
The name is a triplet with the components in reverse order compared to the GNU triplet, <abi>-<kernel>-<cpu>.
If the triplet only has one component the <kernel> is assumed to be linux.
If the triplet is kernel independent then <kernel> should be none.
If the triplet only has one or two components the <abi> is assumed to be the baseline for that port, so uncommon variations should use the three-form triplet (e.g. uclibc or musl variants).