Re: RFC: Idea for improved diversions and alternatives handling
Steve Langasek <email@example.com> writes:
>> FIXME: what if a line changes? Only allow certain changes?
> ... that's a rather large FIXME. Without fixing this, such an
> implementation of declarative diversions would be pointless churn.
> You should perhaps discuss this with Ian Jackson, there have already been
> rumblings from him about implementing declarative diversions.
The problem is that changes in --rename will be insane.
For example package A 1.0 has diverted /usr/bin/foo from package B
with --rename and ships /usr/bin/foo itself.
Now imagine package A 2.0 drops the --rename option.
A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
file is from A 1.0. So you have to move /usr/bin/foo to
/usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
/usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
case of errors you have to revert it all back.
Would anyone have a problem if dpkgs diversion handling would always
use --rename? Because if we eliminate that from being an option the
changes become easy.
Also a diversion without --rename can not be cleanly removed by
dpkg. The original file would be gone for all dpkg knows. Another
reason to always use --rename by dpkg.