5

I have a custom managed package and made it accidentally depend on another managed package. The new package is already installed in some other orgs.

Can I (in a newer version) of my package remove the dependancies from the other package? If not, could Salesforce support do it?

0

2 Answers 2

3

Removing an established dependency from one managed package (call it Core) to another (Extension) is only possible in selected circumstances. In others, the dependency is permanent (1GP) or can only be removed by breaking the ancestry chain and removing any ability to upgrade while losing Security Review status (2GP).

Specifically, removing a managed package dependency is possible if the locations in Extension metadata that reference Core can be modified by the developer after the package version is uploaded and can then be pushed to subscribers.* For example, if Extension has a dependency on Core because it packages a Permission Set that references Core entities, the dependency can be removed because the Permission Set can be edited by the developer (removes the dependency in the packaging org) and then pushed to subscribers (removes dependency in subscriber orgs).

However, if the reference is in components that cannot be changed, such as if Extension packages a global Apex class that references Core types in method signatures, the dependency is permanent barring the very expensive and painful beta-reversion process. In some cases even that may not be able to remove the dependency, such as if a component with a reference is included in a Flow version (which can't be deleted after it's uploaded in a beta package).

It is highly case-specific!

* I have never tried removing a package dependency in a component that is developer-editable but does not push upgrade, such as a Report or Page Layout. I don't know whether this works but requires manual subscriber changes or is blocked by manageability rules; I suspect the former.

3

From my understanding, the only way to fix this is to roll the version that introduced the dependency and all future versions back to a Beta version, which also requires uninstalling that version and all future versions from all subscriber orgs. If that's not realistic (and it usually isn't), then you're stuck with what you have, or you will have to create a new package and eventually switch all your subscribers to that one instead. However, the policy may have changed since I've gone through this process, so you would probably be better off logging in to the Partner Portal and submitting a case. If you're not a partner, you're probably out of luck, as last time I checked, normal support cannot modify a managed package at all.

4
  • I just reproduced this using two play orgs. Even if the extension removes all its technical dependencies to the Base Package and its NOT show as Managed (Extension) anymore it remain dependent. Very dangerous. Commented Jul 26, 2018 at 2:15
  • 2
    @RobertSösemann Yep. That's why they have warnings like not installing the LMA into the packaging org, etc. In fact, it's prudent to never install any packages into a packaging org because of that risk.
    – sfdcfox
    Commented Jul 26, 2018 at 2:19
  • But I don't get why they should not be able or willing to help and reset a package in such rare situations. This can kill companies. Commented Jul 26, 2018 at 21:23
  • 1
    @RobertSösemann The system prevents you from doing things that could break things. For example, if the dependency were removed, and some subscriber had a dependency on that dependency... it'd break on upgrade. They don't say how, exactly, but it's simply not something they're worth risking. That's why the rollback/uninstall process is required, to prevent issues.
    – sfdcfox
    Commented Jul 26, 2018 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .