dependencies contingent on other packages

[Michael Brewer-Davis <michael tech4learning com>]

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.