[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: "--replacefiles" %file directive
- From: Jeff Johnson <jbj redhat com>
- To: rpm-list redhat com
- Subject: Re: "--replacefiles" %file directive
- Date: Sun, 5 May 2002 12:11:18 -0400
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]
[]