Bug#630214: libapt-inst1.2: file conflict with apt 0.8.14.1 (/usr/share/locale/vi/LC_MESSAGES/libapt-inst1.2.mo)

[Michael Vogt <mvo@debian.org>]

On Thu, Jun 16, 2011 at 12:35:29AM -0500, Jonathan Nieder wrote:
> retitle 630214 libapt-inst1.2: missing Breaks against apt versions from before the split
> severity 630214 important
> found 630214 apt/0.8.15~exp2
> quit
> 
> Hi again,
> 
> Jonathan Nieder wrote:
> 
> > Based on the changelog entry
> >
> >    * debian/control:
> >      - add libapt-pkg4.10 and libapt-inst1.2 library packages
> >
> > I am guessing there is a missing Breaks+Replaces.
> 
> Looking over the debdiff, I see a Replaces now but not a Breaks.  The
> Replaces is tracked in Bug#630204 (thanks, Shirish!), so I'll recycle
> this bug to track the Breaks.
>
> As mentioned in policy §7.6.1 (Overwriting files in other packages),
> a person trying the sequence:
> 
>  - unpack new libapt-inst1.2
>  - remove new libapt-inst1.2
> 
> in the process of recovering from a failing upgrade will find that
> /usr/lib/libapt-inst.so.1.2.0 goes missing, and a Breaks is
> recommended to avoid that.
> 
> On the other hand, with Breaks, a friendly package manager might
> update apt first, meaning files are missing in the window between
> when new apt is unpacked and libapt-inst1.2 is unpacked.  (This
> is _always_ a possibility with Breaks+Replaces, hence probably a
> policy bug.)
> 
> I suppose my knee-jerk suggestion would be to make libapt-inst1.2
> Breaks: apt (pre-split) and Replaces: apt (unversioned), to install
> the same files in apt, and to raise a policy bug to fix the advice in
> §7.6.1.  Other ideas welcome, too, of course.

Thanks! I think the breaks is the cleanest solution. I prepare a new
upload with that.

Why do you suggest a unversionized replaces? It seems to me like using
the same pre-split version as in the break should be fine here. Or am
I missing something?

Thanks,
 Michael