Hey, check your pull requests.
Nothing interesting. dpkg -i removes real package and replaces it with fake one. Or I didn't understand you.

Thanks! I checked them within the first 24 hours after you posted that, I've just not had time to respond or address them (I don't 100% agree with the way one or two of them were done so I need to do something more intricate than a simple pull/merge).

You understood me fine. That's what I wanted to double check, I'm glad you already knew the answer.

Alright, after being dormant on this for about a year, I think I will have the spare time within the next day or so to:
A. properly merge/incorporate the pull requests that have been sitting pending.
B. check if any other github work has happened by anyone else who's forked this
C. incorporate some new tweaks/improvements I figured out myself.

..that or I'll end up not having time and I'll just get stuck again for several months before doing anything more on this. Hope not.

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?

#2 sounds more logical. Mind the "target audience" of fkdep - the more "flexible" it is for automatically creating fakes, the more use cases it may find.

/Estel

+1 for Estel re. #2

Wow!
The mere existance of this package is a great indicator for how broken Maemo really is.
It's like taking medicine for a disease where you don't know if the disease's symptoms or the medicine's side effects are worse.

That being said, option #2 is the less insane one.

It's not *that* bad. I mean, the need for such a tool. This is a way for the user to "correct" a maintainer decision to depend on this on that. Debian has the "equivs" program for that (which does essentially the same as fkdep, but fkdep is much cooler because of its rawness

In my Ubuntu days I used equivs to be able to remove plymouth.

Oh, and another anecdote: about 20 years ago I decided to give debian a go (being a hardcore Slackware user from day zero). I tried to install sendmail and postfix (I was a hardcore sendmail user but wanted to try postfix as well). I ended up with a half-broken system (you could not really have both installed even if technically this is no problem at all) so I remember me saying something like "How brainf*cked can one be to create this dependency mess". I left Debian and continued happily with Slackware. In 2010 I gave it a try again (first Ubuntu, then Debian) and it continues to hurt, but I've learned to live with it

(and don't get me started with SuSE, which I also tried in the early days.. it broke completely when migrating from libc5 to libc6!)

Just because Debian has an equally weird workaround doesn't make this any better.
The correct solution for problems like these would be for the maintainer to turn the "optional dependencies" into suggests or recommends.
Clearing this mess should not be a user's task.

Then why did you switch to Debian at all?

Don't worry, I won't. This distro made me fail on my first attempt to leave Redmond. I just didn't see enough differences to justify the learning curve.
When I found myself looking for the control center in Suse and yast in Windows I decided to get rid of it.

I know. I was referring to your "The mere existance of this package is a great indicator for how broken *Maemo* really is." (emphasis added).

Convenience. For a couple of years I actually didn't use Linux at all (I missed the HAL party, which is sort of a good thing and then I came back with some Ubuntu version, which I half-liked. Then I switched to Debian to like it a bit more, and there I am. For now it's SID everywhere (yes, including my VPS! . From what I remember using Slackware would require a bit more maintenance-effort which I cannot afford (it's enough with 3x sid, 3x maemo, 1x ubuntu (wife), 1x android (wife), 1x openelec (OK that doesn't count) and 1x openwrt).

Lol I never used SuSE with a GUI, but one thing I hated from SuSE was that YaST kept overwriting my configuration files. This is something I seriously hate. So far both Slackware and Debian have respected this. SuSE didn't. I only have a minimal experience with Redhat (5.0 I believe. I had kernel 2.0 already), but I think it also had a habit of deciding what's best for me.

Anyway, enough off-topic.