P.S. If anyone has tried the packages produced by this script through the user-friendly way of installing (using file manager to find it and click on it so that it opens to install in HAM), it turns out that HAM refuses to install anything that doesn't have a 'user/*' section, or something like that. I think we already knew this as a community, it's nothing new, but I had forgotten it when coding this script.

I am undecided as to what I want to do: add a bunch of commandline options to enable more user-friendly and HAM-appeasing behavior, or not... I am leaning towards doing so, but in a modular manner:

Add one flag --ham-compatible (to use a HAM-friendly package section "user/metapackages" instead of "metapackages") to fkdep itself.
Create a wrapper script ("fkdep-ham" or something like that) to enable more user-friendly usecases (like moving the .deb file to /home/user/MyDocs after it's created so that the file manager could find it, or just launching HAM outright to install it).

I am looking for feedback on the following:
1. HAM will install packages with the section "user/metapackages", but I am not sure how "proper" that is - I know that upstream Debian has a "metapackages" section, so that's why I chose that section for the .debs fkdep generates initially. Consequently, "user/metapackages" seems like the natural extension of that to appease HAM by making the section start with "user/". But, maybe there's some good argument for using one of the commonly-used-in-repos sections for this, like "user/system". I don't think so but I welcome/invite any explanations as to why I may be wrong here.
2. Should I instead just code a --section commandline argument for fkdep, and implement the choice of section used for HAM-appeasement in the fkdep-ham wrapper? Now that I said this, I'm on the fence. Thoughts/advice?