On 12/21/2015 02:42 PM, Ralf Mardorf wrote:
A package's files cannot conflict with files from itself. There
is another package providing the same files. Such a conflict at least
require two packages providing files with the same name. Note! We at
least had one package providing files in the same path with the same
name that were absolutely different software. I don't remember this file
anymore, I noticed it because I installed both packages. The
maintainers couldn't notice it, because they were not interested in
both domains and were not aware about the other software. Upstream of
both software accidentally used the same name.
This is beginning to make sense, and the use of --force wasn't a misuse as there
was NO other package providing the files. If I understand what is happening, it
is *pear* itself that is causing the conflicts through it's own:
# pear install foo
install routine. In this case it is the pear Console_Getopt package:
# pear list-files Console_Getopt
Installed Files For Console_Getopt
==================================
Type Install Path
php /usr/share/pear/Console/Getopt.php
test /usr/share/pear/test/Console_Getopt/tests/001-getopt.phpt
test /usr/share/pear/test/Console_Getopt/tests/bug10557.phpt
test /usr/share/pear/test/Console_Getopt/tests/bug11068.phpt
test /usr/share/pear/test/Console_Getopt/tests/bug13140.phpt
So there is no packaging issue, with any Arch package, it is a byproduct of pear
install Console_Getopt as part of the eGroupWare install that brought in via the
pear channel network install that brought the duplicate files in. So I'll go
look when these files first appeared in the php-pear package as this was the
first update where they were listed as a conflict. eGroupWare was
installed/upgraded on 8/30/15 following the initial install of php-pear on 8/26,
so it looks like the files were first flagged as conflicting file on the
5.6.14-1 -> 5.6.16-3 upgrade yesterday.
--
David C. Rankin, J.D.,P.E.
