[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Files changing rpm residency...

On Mon, Jan 06, 2003 at 11:57:25AM -0500, James Olin Oden wrote:
> Hi All,
> I have a general problem that I need to understand better.  If you
> created an RPM, and later (i.e. after it was installed on the system(s)),
> you decided that one of its files really needed to be in another RPM 
> or the RPM itself needed to be split up, how do you handle this in upgrade?

Don't do that! :-)

Red hat handles file conflicts as follows:
	0) Initially A.0 has /foo
	1) New B.0 is created containing /foo, A.1 is created w/o /foo.

Normally that's enough, as anaconda/up2date (and users) rely on the heuristic
	An upgrade will usually solve dependency (and here, file conflict)

More anal retentive packaging adds to package B
		Obsoletes: A >= 0
but that often removes other, essential, Provides: that get complicated.
The fix there is to create a "Son-of-A"-common package that contains /foo
and nothing else, thereby making the file conflict problem solvable by
a decision to install (or not) a package.

There's also the issue of discovery that /foo has moved to B from A on upgrade.

Upgrade discovery has been handled in anaconda in the past by looking at all
installed files, looking for a new, previously uninstalled, package that
contains /foo. That search fails with say, /usr/lib/sendmail, because there
may be multiple new, previously uninstalled, conflicting, packages that
contain the file.

Upgrade discovery can have global side effects too. I believe it was Red
Hat 6.2 where KDE was installed by update discovery.

> The problem I see is that the file(s) you move from the first RPM will
> be owned by the first RPM on the install system, and without a force the
> new RPM that contains the file(s) moved from the old RPM will fail to 
> install.  Is this true, and how would one in general solve this 
> problem?

No matter what, rpm has the implicit rule
	Last file installed will override the state of all (if any) other
	identical paths, causing a state change from "normal" to "replaced".
That's basically what happens when you add --force to disable file conflict
problem detection.

Otherwise, there is no general solution to the problem of file vs. package
management beyond
	Don't do that.


73 de Jeff

Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []