Over the years I have run into many packages that insist that they need package X or Y when I don't want it installed, and am fairly confident that what they claim to depend on, I don't need to use. Sometimes the maintainers are very understanding and are open to suggestions or fixing it, sometimes the packages really need it, but either way, the reality is sometimes you want to install a package, which in turn tries to pull in another package as a dependency, and you want to avoid that - this script is for those times.

[edit2]
It takes the name of the package to fake, and optionally parameters to specify the section (default section is "metapackages"), hard/versioned package faking, or to print the basic help text.

The hard/versioned faking requires the package to take on the same name as the real/faked package, whereas without that option it does soft/non-versioned/provides faking where the package generated is named fkdep-[faked-package-name] and just puts the faked package name into the 'Provides' field.

The section parameter allows you to pick another section (e.g. to allow the N900's HAM to install it, which only does it if the section field is in the 'user' area (starts with 'user/')).

The help argument just causes it to print basic help/usage text, and exit. If it's present, the rest of the arguments are, consequently, noops, since the script prints usage text as soon as it detects the argument, and exits right after that.
[/edit2]

[edit2] This following paragraph describes version 1.0 [/edit2]
It takes the first parameter given to it, and (after checking to make sure the name given is a valid deb package name, and that such a package is not already installed) generates a metapackage .deb which will have the name of the package passed in listed in the 'provides' field. If run as root it will install it, if not, it will leave it in a temporary directory for you to install/check manually.

A little bit of background: I wanted this to have no dependencies beyond what's on the N900 already in the stock install, which was a problem because a .deb file is actually an 'ar' archive containing two .tar.gz archives and one text file. Fortunately it turned out that the 'ar' 'common' format, which is what 'deb' files are, is trivial. It's essentially all of the files concatenated, with some metadata prepended to each file.

http://en.wikipedia.org/wiki/Ar_%28U...format_details

As a result, it is fairly straightforward to implement it using cat, printf/echo, ls+awk / wc to get the file size, and expr [edit3]or the shell's own arithmetic expansion[/edit3] to do modulo-2 on the file size, because file entries have to be 2-byte aligned.

I was going to wait until this was uploaded to the repository[edit3](as of 2015-02-19 I have uploaded it to the repos)[/edit3], but I was starting to hijack the thread where I originally brought it up already, so I didn't want to keep doing that, so here it is.

https://github.com/mentalisttraceur/fkdep

[edit1]Changed title from WIP to Announce. I was calling it a WIP because a single bug was reported, which I wanted to investigate. I had already tested it, but I was waiting until I got around to testing once more on a completely stock N900 setup. It worked fine there too, so I'm very confident it's usable as is now.[/edit1]

Carrying this post in from the Busybox thread where this started:

Odd, I just tested your exact usecase, works for me with dpkg -i, dpkg -x, and dpkg -e. (Generated the fkdep-adduser.deb twice and tested those commands on both just in case.)

I will definitely test this in my absolutely stock N900 that I have laying around for these moments as soon as I get the chance (not for a few hours at least), and I'll let you know.

In the meantime, can you please send me that .deb file?

Oh, of course. I would expect nothing less. You gotta check that stuff.

peterleinchen:

I have just tested on my absolutely-stock N900, and no errors about bad file magic as well. I went to the github repo link, clicked on the file, clicked the 'Raw', and saved the page, which saved as fkdep.html, but was just the plaintext copy of fkdep, so I moved that into /tmp, chmod +x 'ed it, renamed it to just 'fkdep' (for aesthetic purposes) and ran it. Both dpkg -x and dpkg -e worked perfectly without issues.

I'm going to go ahead and bill this as a problem on your end. Can you open the file and view it [Edit 1: by it, I mean the fkdep script itself] to make sure that however you downloaded it, it saved correctly? If you manually selected and copy-pasted from the 'user friendly' default view github provides of code files, then there might be meta characters or maybe line numbers and stuff that got inside the resultant script in the process.

Check
Sent out.

Of course I am not on stock but with kp52, bb-power, gnu-tar and all other devel stuff!

After investigating with 7z I am not any point further. The zipped part of control.tar.gz and also data.tar.gz looks okay (when extracted it is a valid zip file). And removing those parts from fkdep.deb will also bring a valid zip.

Here's your problem:

For some reason, whatever way you got the fkdep script, the white space got collapsed. The fields are padded with spaces to 16 characters for name, 12 characters for timestamp, 6 characters for both UID and GID numbers (the two zeroes), 8 characters for the permissions (the 100644) and finally 10 characters for the filesize.

I used the printf "%-[#]s" syntax for right-padding the variables for filename ($1), timestamp, and filesize, but since 0, 0, and 100644 are constants for our purposes, I have the exact number of padding manually entered in there. So it's supposed to be 5 spaces after each 0 and two spaces after 100644, instead of one space after each.

Thanks, will check later.
Got it with N900 (c/p from browser) directly, not from raw code, but formatted one. Pasted content into leafpad and saved ...

Fetched once again via github and RAW tab and it works!

This script could provide an effective way to uninstall some of the default packages without breaking the Maemo metapackage. I'm thinking for example in those applications that have an open source replacement (such as Media Player or File Manager) and default desktop widgets (usually the ones in repos are far better).

Have you tried to create an empty package to substitute an already installed application?

Yes, it works exactly like this.

Just an example:
tor in its latest version wants adduser as a dependency. So one needed to install that even bb-power provided enough functionality to guarantee the correct working of tor (as in earlier versions).
So install fkdep-adduser and you may safely remove adduser without apt-get removing tor with adduser.

Mission accomplished.
Just make sure you have an alternative for what you want, here: bb-power providing adduser functionality (would need symlinking /usr/sbin/adduser again to busybox or reinstalling bb-power after removal). But that is easy peasy for people playing with such stuff, right?


--edit
this is valid only for 'unversioned' dependencies, see MentalistTraceur's detailed answer in next post!

The short answer is yes for some, not-yet for most.

The long answer requires a quick explanation of how Debian packages work as far as 'depends' and 'provides' fields go.

Basically, when you specify a dependency in the 'Depends' field, you can just specify the package name, or you can specify a package name and a version (either an exact match, or a greater-than(-or-equal-to) or a less-than(-or-equal-to)) - this is called a 'versioned' 'Depends'.

The packages listed in 'Provides' can never have a version specified. The rationale is that when a package maintainer creates a dependency on a specific version, they're saying "no, you definitely need exactly this package, of this version".

Since fkdep currently only creates packages with the 'Provides' field containing the 'faked' package name, fkdep cannot currently help displace packages that are a 'versioned' dependency of another package.

In their infinite wisdom, Nokia designed the overall PR metapackage to have almost all of the dependencies be strict versioned dependencies. I.e. instead of depending on just the package 'mediaplayer', it depends on package 'mediaplayer (=1.3-4+0m5)' or something like that.

Aside: luckily, for those of us using the CSSU (at least CSSU testing), the dependency on some packages, like mediaplayer, is actually completely removed from that metapackage, and most of the dependencies are more permissive: >= ones rather than strict =.

But as far as fkdep accounting for faking 'versioned' dependencies', there's two things that need to be done, one is easy, the other is a lot harder.

One, it needs to create packages with the same name and version number as the 'faked' package. This is not a problem technically, in fact that part is rather trivial, and is going to be a feature I will add soonish in my spare time. Though it is a bit more of an issue philosophically - it would actually pretend to be the package it's faking, rather than being a differently named package pretending to offer the faked one. (Management by the user is less 'clean', instead of just deleting 'fkdep-*' you'd have to remember what fake-name package you actually installed by name, unless I had it add both a name-duplicate one and a fkdep-* one, the former depending on the latter, so you could still manage them by keeping track of just the 'fkdep-' named ones...)

Two, though, is that if the package is already installed, and there is a hard dependency on the same version, I'm not exactly sure what happens. I will test shortly - on CSSU, you can uninstall the mediaplayer package. I will test by making a fake package named mediaplayer with the same version, and trying to install it. We'll see from there. This won't be in the immediate future though, I have to catch up on academic work while keeping up with actual employed work.