On May 10, 2016, at 6:30 AM, Elan Ruusamäe wrote:
> On 10.05.2016 09:12, Jeffrey Johnson wrote:
>>> Fixed in lirc-0.9.3a-2 / man-pages-4.05-2.
>>> >
>> Is file conflict detection an RPM misfeature?
> no. it's packaging mistake (two packages installing same file path)
>
Of course it is a packaging mistake: I have fixed dozens of file conflcts
from duplicate man pages
The question was about detecting and failing an rpm upgrade
when there is duplicate content. EVen when content is identical,
there is a timestamp in some compression formats (yes there is an
option to remove the timestamp), and/or the buildtime on the file can/will
differ.
There are alternative automated resolutions other than human intervention
to rebuild the package that might be attempted.
>> It would not be impossibly hard to resolve a file conflict automatically,
>> perhaps with an alternatives-like symlink farm analogue mechanism
>> to permit multiple copies to coexist.
> there's no alternatives, two packages should not provide same file.
>
Alternatives (fundamentally) is just a symlink to a unique file path. RPM
could easily install the file on a unique path and install a symlink, and
even add the configuration so that alternatives(8) (literally) could be
used to resolve the file conflict on the machine being installed.
All of the above has to do with automating (at least temporarily) the
install instead of just failing.
> lirc one was the outdated one, according to commits made.
>
There are other relatively simple automations:
1) FIFO - first version is installed, all other file versions are
skipped.
2) LIFO - last version clobbers all other file versions.
3) largest - the bigger file is installed
4) newest - the newest modify time is installed
5) masked - a file conflict automated resolution is read from
configuration.
The majority of manual file conflict resolutions are one of the above.
There's also a means to detect file conflicts at buildtime and fail the build,
not the install later, if rpmbuild attempts to maintain a collection of all
current
headers in a database, and checks for file conflicts at the end of successful
builds.
73 de Jeff
> --
> glen
>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
