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.