Bug#630214: libapt-inst1.2: file conflict with apt 0.8.14.1 (/usr/share/locale/vi/LC_MESSAGES/libapt-inst1.2.mo)
Hi Michael,
Michael Vogt wrote:
> Thanks! I think the breaks is the cleanest solution. I prepare a new
> upload with that.
Thanks!
> 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?
I was musing about something that doesn't have much to do with apt.
Worse, I blindly assumed that libapt-inst1.2 is part of the
"important" part of apt, but it doesn't seem to be. So no, I don't
think you're missing anything.
Sorry for the noise.
Regards,
Jonathan
For completeness:
With a Breaks, we are declaring to package managers at the new
libapt-inst1.2 cannot be unpacked at the same time as the old apt is
configured. For simplicity, suppose I am invoking "dpkg" directly and
I refuse to ever use a --force- argument (really, one should imagine a
high-level package manager refusing to violate policy, but this is
simpler). How do I perform the upgrade?
I have two choices:
A) Unpack apt before libapt-inst1.2.
With this upgrade path, first /usr/lib/libapt-inst.so.1.2 vanishes
from the filesystem, and then it returns again moments later. If
lacking libapt-inst.so.1.2 were a situation that is hard to
recover from, that would be a problem (but luckily it isn't, as
mentioned above).
B) Unpack libapt-inst1.2 before apt.
This upgrade path avoids the temporary disappearance of the
DSO mentioned under (A). If I am stupid about it, it won't work:
# fails because it Breaks apt!
dpkg --unpack libapt-inst1.2_<new version>.deb
What I should actually do is
dpkg -B -i libapt-inst1.2_*.deb; # deconfigures apt.
dpkg -i apt_<new version>.deb
If deconfiguring apt creates a situation that is unpleasant or
hard to recover from, that would be a problem (luckily there
does not even seem to be an apt.prerm, so no trouble in this
case).
Really, I was just confusing myself about why the Breaks wasn't there
in the first place --- sorry about that. A reasonable conclusion
would be that moving _essential_ files between two packages is a pain
in the neck that requires the ugly
C) Change the packages to _both_ provide the file that moved between
them, so upgrade path (A) does not involve any temporary
disappearances from the filesystem.
Luckily it doesn't happen so often.
Reply to: