Linux Archive

Linux Archive (
-   RPM Package Manager (
-   -   dependencies contingent on other packages (

Michael Brewer-Davis 07-07-2008 05:56 PM

dependencies contingent on other packages
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,

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
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

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

All times are GMT. The time now is 08:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.