dependencies contingent on other packages

[Michael Brewer-Davis]

I'm trying to achieve the following while installing package "main":

If user has package "maybe" installed, then require package "extra"

Is there any manipulation of requires:, obsoletes:, triggers, etc.,
that would help me accomplish this?

Thanks much for any advice,
michael

----
Background:
I'm trying to restructure our packages. Where before we had one
package, "old_first_app", which included all our files, we now want to
have
new_first_app
second_app
common
where the "common" package is a common dependency of "new_first_app"
and "second_app". "new_first_app" and "common" both conflict with
"old_first_app" (because "old_first_app" installed the common files as
its own).

The issue comes with "old_first_app" users installing "second_app"--
they need "common" but it conflicts with "old_first_app". I'd like to
require users install "new_first_app" in this case. If they didn't
have "old_first_app" I don't want to require they get "new_first_app".

"old_first_app" is becoming "new_first_app" because its package name
wasn't kosher ("OldFirstApp" instead of "ourcompany-old_first_app",
with potential conflicts with other apps, etc.).

Approaches I've considered:
Obsoletes: If "common" obsoletes "old_first_app", common files get
overwritten. But "old_first_app" also disappears (at least on my test
system)

Requires: I could require a newer "old_first_app" version, which in
turn required "new_first_app" and released its own files. But then
both "old_first_app" and "new_first_app" would show up in the
repository, which would be confusing.

Forcing: We could have users force overwriting files in the
installation process, but that would prevent people from using nice
tools and would scare them.