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.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
