Might as well open this up to wider discussion:
What SHOULD be done with RPM file conflicts?
(aside to Per Oyvind)
Yes I agree there's no "actual need".
And the real fix is in XZ (if interested). This isn't
the first time that file conflicts have shown up
in multilib packaging (or with dueling man pages).
The "fix" (sic) at the time was to invoke "gzip -n"
during rpmbuild to remove the time stamp (and path)
from the compressed man page. That was almost good enough too,
except that some builds installed their own compressed
man pages, and so man pages needed to be recompressed with -n.
I'm almost certain (but have lost track) that XZ has the same issue,
that there's a time stamp in *.xz/*.lzma that forces content differences.
Begin forwarded message:
> From: Jeff Johnson <[email protected]>
> Date: December 28, 2010 10:18:40 AM EST
> To: Eugeni Dodonov <[email protected]>
> Subject: Re: [Cooker] Replaced files in *.rpm packages
>
>
> On Dec 28, 2010, at 6:48 AM, Eugeni Dodonov wrote:
>
>> On 12/28/2010 08:11 AM, Jeff Johnson wrote:
>>> Hi --
>>>
>>> In order to figure out how to fix an issue with
>>> RPM, I need some input on Mandriva (or any other)
>>> system regarding replaced files.
>>>
>>> A "replaced" file is a path contained in more than
>>> one package with different content or stat(2) metadata.
>>>
>>> What I need is this output (before upgrading to rpm-5.3.6+):
>>> rpm -qas | grep "^replaced" | wc -l
>>>
>>> Private replies are likely preferred, the output is technically
>>> mind numbing and otherwise stultifying and utterly uninteresting.
>>>
>>> (aside)
>>> I'd also be interested in the actual paths if the output
>>> isn't huge.
>>>
>>> My hunch is that there aren't any replaced file states, and
>>> I need a confirmation before ripping out some ancient code.
>>>
>>
>> Hi,
>>
>> here are my stats:
>> [eug...@eugeni-x86_64 09:44:23 ~] $ rpm -qas | grep "^replaced" | wc -l
>> 8
>> [eug...@eugeni-x86_64 09:44:38 ~] $ rpm -qas | grep "^replaced"
>> replaced /usr/share/man/man3/ExtUtils::CBuilder.3pm.xz
>> replaced
>> /usr/share/man/man3/ExtUtils::CBuilder::Platform::Windows.3pm.xz
>> replaced /usr/share/man/man3/Compress::Raw::Zlib.3pm.xz
>> replaced /usr/share/man/man8/ifdown.8.xz
>> replaced /usr/share/man/man8/ifup.8.xz
>> replaced /usr/share/man/man3/crypt.3.xz
>> replaced /usr/share/man/man3/crypt_r.3.xz
>> replaced /usr/share/man/man1/gpg-zip.1.lzma
>>
>
> Thanks.
>
> All the examples I've seen in Mandriva are in man pages.
>
> (aside)
> I can guess from the paths in Per Oyvind's filtering patch that there may be
> a few more cases.
>
> But that's enough data for me to ascertain what to do (likely rip-out some
> ancient code. Alternatively, there's an rpmdb access deadlock on this
> same code path).
>
> Which brings me to the next level
> How/when/where should file conflicts be detected?
>
> Any interest in expressing Mandriva Cooker needs? The two
> extreme view points on "file conflicts" are:
>
> 1) rpm should _NEVER_ do anything unexpected, should always FULLSTOP
> when unexpected is detected (which has a certain cognitive dissonance).
>
> The problem here is that FULLSTOP creates a support issue, and
> it takes a bit to fix, build, distribute, install a new package,
> so the problem is usually reported multiple times, and often
> reappears.
>
> One solution here is to attempt a check while building. In the
> case
> of file conflicts, 2 packages are independently constructed.
> What
> could be done is to automate file conflict detection during
> rpmbuild
> using a reference database (i.e. an rpmdb) of "everything". The
> difficulty then is maintaing a proper reference database: any
> check will be only as good/bad/ugly as the reference database
> is.
>
> 2) rpm should do "best effort" and attempt some reasonable resolution,
> possibly
> logging the problem case.
>
> The problem here is that noone will ever read the log, nor
> understand
> and fix the problem.
>
> What's your Mandriva Cooker POV?
>
> 73 de Jeff
>
>
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
