On Dec 28, 2010, at 11:28 AM, Mark Hatle wrote:
> I've always thought fileconflict mechanism that simply checked md5/sha1, mode,
> owner and group would be adequate. The creation time I would expect to be
> different between packages.
>
When time stamps are added to content, its not just st_mtime, but content
failures.
Hysterically, st_mtime handling in RPM is due to the alpha miata and its
whacko clock.
> In the case of compressed man pages, this seems like it would require special
> processing to be able to deal with the same file, that was compressed slightly
> differently. I'm not sure if it makes sense to write a generic hook for this
> (decompress & then compare), or if it's just a system packaging error.
>
The generic hook using "gzip -n" recompression has long since been written
and buried in some brp-foo script. But XZ appears not to have a --no-name/-n
switch
like gzip does.
I'd tend to agree: packaging error. But that isn't my call ...
Meanwhile what I'm asking about file conflicts is at a much higher level.
Originally, rpm is/was _THE_ tool for doing distro QA.
And so there's still code in RPM that is overly strict (imho) and backwards
in intent these days:
RPM should be about installing content, not detecting and causing
installers
to come FULLSTOP in media res.
So I believe its time to move the distro QA into rpmbuild hooks, and
to automate some of the file conflict detection during build, not install.
E.g. the discussion about markReplacedFiles() affects the file state "replaced".
There are like 10 "replaced" files (out of 300K -> 1M files in a modern distro
like Mandriva) that actually have the state "replaced". All of the paths
reported are/were due to man-page compression afaict (all paths were
/usr/share/ma/...)
Is it truly worth the effort for 10 files out of 1M? I can assure you that
the code path that invokes markReplacedFiles() in RPM is totallu obscure and
quite painful to "fix" and maintain. I don't believeanyone really
knows or uses file states in RPM either. I do know that no one has asked
for years about "file states".
To restate, which goal should take precedence in RPM:
Preserving "traditional" functionality (I claim "useless")
_OR_
Streamlining the RPM installer toremove Baroque'ness
Yes file conflicts are important information for build momma's. I'm not
suggesting eliminating file conflicts everywhere, just getting better process
in place _BEFORE_ the install starts on an end-luser box.
73 de Jeff
> --Mark
>
> On 12/28/10 10:19 AM, Jeff Johnson wrote:
>> 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]
>
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List [email protected]
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
