On Dec 27, 2010, at 9:42 AM, Per Øyvind Karlsen wrote:
>>
>> Are all these file conflicts with compressed man pages?
> These conflicts are all related to any files found under those paths,
> independent of compression or not. The original motivation was related
> to coloring, whereas we treat non-identical files of different color
> as conflicts, while not caring to be as strict for doc conflicts
> between packages wrt. multilib -devel packages etc..
>
Yes multilib adds a great deal of differing content on identical paths.
IMHO, this is a packaging, not an rpm implementation, issue, and
needs to be addressed in packaging. Hacking on rpm can only treat
symptoms by fiddling around with band-aid mechanisms that will
never ever succeed.
> Looking at the resulting conflicts I've run into, these have all been
> different kind of conflicts not related to what originally aimed at
> (between multilib -devel packages), so this patch should probably be
> made stricter and only apply to files of different coloring built from
> same source package... WDYT?
>
See above.
Meanwhile I strongly believe that _RESOLVING_ file conflicts by policy
rule, not muck-a-bout detecting and coming FULLSTOP, is what is needed.
The traditional resolution policies in RPM (rather flimsily implemented) are
With two packages of same N, prefer "newest".
With two arches, score and prefer (_NOT_ done by rpm meaningfully).
With differently colored executables, choose the preferred color.
Your hacky patch adds a disabler based on path. The "hacky" is that the
paths are compiled into rpm, which cannot possibly satisfy everyone.
Other policy resolutions are quite easy to devise:
Prefer the later buildtime (heuristic is later == better, good for
distro)
Prefer the earlier buildtime (heursitic is earlier == better, good for
sysadmin)
Prefer the larger/smaller file.
A policy rule based resolution isn't impossibly hard to conceive of either,
with patterns matching path/content_type/etc, and an assignment to the
file resolution based on the context, all done in YAML/XML/JSON markup spewage.
> I need to take a closer look at the files conflicting, but I suspect
> most of the conflicting files might be non-identical, thus considered
> packaging mistakes to be fixed, currently masked by this patch...
>
non-identical == conflicts
Well duh.
So the issue is that you are not happy with the intended result
and choose to blame the implementation and do hack-o-bout.
What's really needed is to back off from the details, and figger
a more flexible/tunable framework, including pushing %config content
into a VCS not leaving *.rpmnew/*.rpmsave turds on the file system.
WDYT?
hth
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
