I fear this is a very bad example because what happened here should really not have happened. It is an exceptional situation and thus exceptional measures were necessary.
Apt tries to first fix the mess before it installs anything. You had the kernel image in a half-installed state and apt tried cleaning that up but it cannot because to remove the package, the post-removal script needs to run and that also failed. That’s why it worked to not use apt and just use the underlying dpkg instead. Fix the package that was the cause of the problem and now the kernel can be installed correctly.
With that definition a lot of packages should probably not be “optional”. The importance of that field is also shrinking over time. In the past it was useful to let debootstrap support differently large chroots. These days, not many places rely on this value anymore. For example consider container environments: they don’t even need an init system even though that one is normally also required to… boot.
I can tell you more about what happened here and if you keep asking questions I will answer. Just please consider that if you are a beginner, this is not the most friendly topic to start nor is it the most useful because situations like this will hopefully never happen again. To give you an idea of how complex this topic can become consider this graphic:
You started at the upper left at “1.2-3->prerm upgrade 1.2-4” because you are upgrading a package (the kernel). The prerm script was OK so you go to “1.2.4->preinst upgrade 1.2-3” and because of a bug in linux-base, that step FAILED so you go to “1.2-4->postrm abort-upgrade 1.2-3” which also FAILED so you are getting an error and the package is left in the state “Half Installed (1.2-3) Reinst required”.
@josch That did the trick for me as well! Thanks for the fabulous support and the detailed explanation. I appreciate issues if I can learn from them, you made this one very likable!
Thanks again @josch for the help and explanation! One last question: that flowchart is from an appendix of the Debian Policy Manual right? I’m a Debian novice but I like to have some understanding of the data structures and algorithms in my software. The Policy Manual seems pretty approachable and I’m slowly going through it, but is there something else I should read before or concurrently? Currently I’ve queued up:
What exactly is it that you want to do in the end? The Debian Policy manual is usually useful for those who want to write Debian packages that are meant to be uploaded into the Debian archive. If you don’t want to upload your packages there, then there are much easier ways to create Debian packages because then you do not need to adhere to these rules.
That part of the manual is interesting if you want to set up your own Debian mirror without using existing software (like reprepro and aptly) but instead want to do it yourself.
The first four documents on that list are great resources for everybody who wants to contribute to Debian.
This is about debmake. I think using debmake is a good idea if you just want to create a Debian package and share it as it is or in your own private repository. It might also be nice to get started quickly and avoid the otherwise quite steep learning curve. Though I would be very surprised if anybody would use debmake for anything “serious” in the sense of maintaining packages in the Debian archive.
