[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: