[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)
	issues.

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.

HTH

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