[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

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.


Reply to: