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

Re: Breaking /emul/ia32-linux for squeeze



Steve Langasek <vorlon@debian.org> writes:

> On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
>> Josselin Mouette <joss@debian.org> writes:
>
>> > Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
>> >> Say you have acrobat reader installed which depend on ia32-libs-gtk.
>> >> You also have libgtk2.0 (i386) installed with a newer version that
>> >> breaks acrobat reader (like it did last year). Then acrobat reader
>> >> will use the newer libgtk and break despide the dependencies all being
>> >> correct.
>
>> > How is it any different from acrobat on i386 breaking when you upgrade
>> > GTK+ the same way?
>
>> Depends: ia32-libs-gtk (<= 2.6)
>
> Where is the package that does this?

Patched from marillats old package.

> How does this package know, a priori, that the next version of libgtk2.0
> will break it?  It's considered a bug if a library breaks its public
> interfaces without changing soname; consequently it would also be a bug for
> this package to second-guess libgtk.

I patched that in after the fact so I wouldn't accidentally upgrade
the system to a known broken combination. Since the acroread package
is locally build that was easier than patching libgtk to conflict with
acroread.

Anyway, my point was more the fact that it depends on *ia32-libs-gtk*
and *not* *libgtk2.0-0*. Acroread would break by something that is not
listed, directly or indirectly, as depends.

>> Also some libraries do have conffiles or binaries and will get into a
>> file conflict with or without the multiarch library path. They need a
>> Replaces/Conflicts line anyway. Chief among them libc6 (i386)
>> vs. libc6-i386.
>
> That's true, but not a reason to cause file conflicts for all the other
> biarch packages out there.

MfG
        Goswin


Reply to: