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

Re: "--replacefiles" %file directive



On Sun, May 05, 2002 at 02:21:13PM -0000, Jaco Greeff wrote:
> Hi,
> 
> I've got the following scenario: For the rpms I'm building, I would like to
> have some way of instructing RPM through the %files list to ignore conflicts
> with files from other packages and just replace them. (a macro for the
> commandline --replacefiles) I'll schetch the scenario, maybe there is
> something I can already do to get around this.
> 
> The packages that I'm currently busy with allows for different spash screens
> in KDE 3.0. Currently I'm building kdebase to "require" "kdelook-splash"
> which can be provided by any number of packages. By default, in my kdebase
> compile, it creates a subpackage, kdebase-splash which provides
> "kdelook-splash" as required by kdebase.
> 
> Now, I've also got a number of packages providing the splash functionality.
> They all provide "kdelook-splash" as to not break. On installing these, I
> need to do a "rpm --replacefiles -i kdelook-splash-liquid-0.9.4-1.i686.rpm"
> as to overwite the default files. I would like this to happen automagically,
> for instance, by specifying (in the replacement and original splash packages)
> 
> %files
> %allowreplace /usr/share/apps/kdesplash/pics/whatever.png
> 
> to allow the "--replacefiles" option to be excersised automatically. I could
> always use "obsoletes" for the replacement package, bvut would like a more
> generic solution since the replacement splash screen can come from a number
> of packages, I don't want to list the obsoletes in all of them to take care
> of this. I've tried to obsolete "kdelook-splash" and also provide it, but it
> still complains due to the virtual package. 
> Any ideas or comments will be appreciated.

While I understand the pain that file conflicts cause for a packager,
I point out that detecting conflicts is useful for the person (not you, the
packager) who is installing a package.

Pemitting file conflict overrides leads to mix-n-match package management,
muddles dependencies (what if you override a conflict with a file that
has dependencies that were added to the other package?), and generally creates
a mess of package management in favor of file management.

Use --replacefiles, or figger a better packaging scheme. For starters,
rpm-4.0.4 now has reasonable support for alternatives (although
I'm not sure that alternatives is a much better solution than
%allowreplace, there are any number of problems I can see).
See the sendmail/qmail and cups/lprng packages in Raw Hide.

FWIW, the usual way of handling file conflicts is to factor the conflicting
files into a common sub-package that can then have 2 (or more) variants. The
file conflict is resolved at the package management level by choosing
one of the variant but otherwise equivalent packages.

An even better solution is to figger a new package that is better than
any of the variants with conflicting files.

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