|
Size: 3601
Comment: updating packages with broken prerm
|
Size: 3758
Comment: Move prerm upgrade Q to behavior, add new item to build flags Q, and other minor tweaks
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| == Q: What can I do when the dpkg lock is held? == | == Q: What can be done when the dpkg lock is held? == |
| Line 9: | Line 9: |
| 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. | 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. |
| Line 20: | Line 20: |
| == 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, independant 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. [[https://lists.debian.org/debian-devel/2000/04/msg00298.html|Proposed by Joey Hess]]. |
|
| Line 22: | Line 28: |
| == Q: Can we add support for a new compressor for .dsc packages? == | == Q: Can we add support for new compressors for .dsc packages? == |
| Line 44: | Line 50: |
| following things would need to be done: * A test rebuild of the whole archive w/ and w/o, and a comparison to see if there's no difference in the amount built. * A comparison of the build logs to see the memory and build time difference (sbuild should provides those). |
following things would need to be done: * 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. * A comparison of the build logs to see the memory and build time difference (sbuild should provides those). |
| Line 49: | Line 56: |
= Packaging Questions = /* Please move this section if more appropriate elsewhere or another page. */ == Q: How to make an update for a broken package with a harmful prerm? == A: There is a way to avoid invoking the old prerm script if it is harmful, but this is not required if it is a simple failure, or does some action that can be easily reverted by the new postinst. Make a new, independant package that replaces the broken package's prerm, and then make the new version of the broken package pre-depend on it. [[https://lists.debian.org/debian-devel/2000/04/msg00298.html|Proposed by Joey Hess.]] |
User 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.
Behavior Questions
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 upmost importance, and this kind of change has always been considered as so.
As of now, this should be handled by the package maintainer scripts, 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, independant 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.
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 default build flags to dpkg-buildflags?
A: Certainly. But before considering adding any flag to the default, the following things would need to be done:
- 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.
- A comparison of the build logs to see the memory and build time difference (sbuild should provides 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.