%config causing file conflict error

jupiter jupiter.hce at gmail.com
Sun Aug 26 06:31:55 UTC 2012

Thanks Greg, great appreciate your explanation.

Kind regards,


On 8/25/12, Greg Swift <gregswift at gmail.com> wrote:
> On Sat, Aug 25, 2012 at 6:40 AM, jupiter <jupiter.hce at gmail.com> wrote:
>> Thanks Greg. Please embedded comments.
>> On 8/25/12, Greg Swift <gregswift at gmail.com> wrote:
>>> As far as i am aware there is no disabling that.
>> So there is not tag in rpm spec to have the same function of forcing
>> installation (force replacement) without using --force? I thought if
>> you can do something in rpm command line, it should have the same
>> functional tag in spec, very much like to use "Autoreqprov: no,
>> Autoprov: no, Autoreq: no" for --nodeps, right?
> Most of those macros and functions are to affect things buring the RPM
> build process, not at install time.  The ones you mentioned are not
> actually equivilent to --nodeps.  They tell the built in RPM functions
> to not try and 'discover' what teh requirements and provides are.
> Typically you would use these because they are finding the wrong
> things, or more than is necessary.  You would then use the manual
> Requires and Provides to make the RPM dependency chain correct.
> Turning them all off and then not manually specifying things does
> behave similarly to --nodeps, but only because there are now no
> dependencies.
>>> I see what you are doing,  but can you explain why? Maybe we can give a
>>> better answer knowing more.
>> As I said, I have two applications sharing the same configuration file
>> (There is a reason for doing it, let's not try to change it). If none
>> of the application package is installed, the first one instals the
>> configuration file, then the second application package should do
>> nothing if it finds the configuration file has already been there.
>> Although the "%config config.txt" is used in spec, I really don't mind
>> if the configuration file is overwritten or not as long as it is
>> there.
> So if the applications MUST use the same config file I believe the
> best path forward would be to break the config into a separate package
> and have both of the original packages Require it.  You said that it
> can have different content, depending on the two parent packages, but
> I can also install both packages.  I would do my best to make sure the
> config file works for both at the same time, and comes out of the box
> that way from the separate package.
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list

More information about the Rpm-list mailing list