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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to