FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > RPM Package Manager

 
 
LinkBack Thread Tools
 
Old 07-07-2008, 05:56 PM
Michael Brewer-Davis
 
Default 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,
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@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
 

Thread Tools




All times are GMT. The time now is 02:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org