Re: RFC: Idea for improved diversions and alternatives handling
On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <vorlon@debian.org> 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.
Er, I've for the life of me never understood why --rename is even an
*option* to dpkg-divert. What does dpkg-divert do without it, and how is
that useful?
I don't think that the meaning of dpkg-divert (without --rename) should be
changed, but I think that for declarative diversions, it makes sense to only
support "rename".
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: