Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Aug 21, 2009 at 11:07:31AM +0200, Goswin von Brederlow wrote:
>> > Concretely, as I have argued previously, there is a difference of scale
>> > between ia32-apt-get and other related tools. dpkg-cross is ugly, but it is
>> > low level and therefore has built-in barriers to adoption; it's not a tool
>> > that casual users are going to use to cross-install arbitrary libraries,
>> > it's a tool that embedded developers can use as a basis for their own
>> > private infrastructure to set up and maintain cross-build environments.
>
>> > It also, last I looked at it, was entirely free of the potential multiarch
>> > file conflicts discussed in this bug. (I acknowledge that you have agreed
>> > to address these issues for ia32-apt-get, but at the time the package was
>> > removed it's my understanding that they had not been addressed.)
>
>> True. But I have never been asked to address them. Implementing
>> compatibility with multiarch requires multiarch to be implemented at
>> least party. You can not expect ia32-libs-tools to be compatible with
>> multiarch before it even was specified what it is.
>
> In http://lists.debian.org/debian-devel/2009/03/msg00638.html ff., I asked
> that biarch packages (which encompasses ia32-apt-get) not install anything
> into the multiarch library paths, to keep these paths clear for the
> multiarch implementation. You asserted that there was no need to do this
> because multiarch packages would already need to conflict with corresponding
> biarch packages, a premise which I have never accepted.
>
> While not a statement that ia32-apt-get *would* use these paths, it seemed
And it never has used them.
> clear that you didn't consider it a problem if they (and related packages)
> *did* use these paths.
That was based on my premise that the biarch and multiarch package of
a library should never be installed at the same time. Binaries would
get the wrong library if versions differ and potentially not work. You
seem to disagree with that. If you take that premise away then
obviously using the same file location is a problem.
> The path structure of multiarch is one part that has been specified for
> years. You can hardly claim to have been unaware of this.
The initial idea was to leave libraries in that path if packages
natively already use that path. Sorry that I forgot about your
previous objection but that is why it is good to discuss plans. I
agreed not to use the paths, i.e. move libraries out of there even if
the native package has them there. So I consider that problem
resolved.
MfG
Goswin
Reply to: