Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Andreas Barth <aba@not.so.argh.org> writes:
> * Goswin von Brederlow (goswin-v-b@web.de) [090809 17:43]:
>> Andreas Barth <aba@not.so.argh.org> writes:
>> > * Goswin von Brederlow (goswin-v-b@web.de) [090809 06:44]:
>> >> My plan is that it will be reduced to nothing as stages of multiarch
>> >> get implemented and finaly be removed. But multiarch will need time to
>> >> get there and ia32-apt-get probably will add extra value to it until
>> >> multiarch can enter round 2 after having been around for a full stable
>> >> release cycle.
>> >
>> > Can you please say how you pkan the different stages of multiarch, and
>> > when are they due? Is this plan coordinated with someone (release
>> > team, ftp team, dpkg maintainer, ...)?
>>
>> I don't think that is really relevant to the question of wether
>> ia32-libs-tools should be in the archive or not. Right now there is no
>> multiarch and right now ia32-libs-tools is a valuable tool for many
>> users. Even if there would be absolutely no plan to support multiarch
>> it would be just like ia32-libs, ia32-libs-gtk, dpkg-cross or apt-cross.
>
> Well, e.g. if we would learn from the discussion that ia32-libs-tools
> will be in the archive only till end of August anyways, I think our
> decision is quite obvious.
Multiarch progress:
Core Toolchain support (binutils, gcc): Done after 5 years
Dpkg support: 0 lines of code in Debian
Apt support: 0 lines of code in Debian
Aptitude support: 0 lines of code in Debian
Synaptic support: 0 lines of code in Debian
Cupt support: 0 lines of code in Debian
Support from the other 20k packages: 0 lines of code in Debian
Add to that: One stable release cycle needed for stage 2 support.
I would not hold my breath waiting even for only stage 1 support.
But lets assume that all gets done till the end of august. Then
ia32-libs-tools should still be in Debian so it can transition the
ia32-libfoo packages users have installed into the multiarch versions.
So no matter what timeline you assume ia32-libs-tools has its use.
> [ resorted ]
>
>> > Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)?
>>
>> Make that "multiarch" (Tollef) and "multiarch" (Ubuntu). The
>> difference between the old and the new proposal is superficial. The
>> part that affects ia32-libs-tools is that "Multi-Arch: yes|no|unset"
>> became "Multi-Arch: same|foreign|unset". From a coding point of view
>> it really makes no difference which of the two will be used and
>> whatever dpkg/apt will use I will use.
>
> So basically everything (except some values in apt) is the same? Did
> Tollef agree to the steps below?
>From the Ubuntu Wiki:
Created: SteveLangasek
Contributors: SteveLangasek, HectorOron
I have no idea if Tollef is involved in the Ubuntu multiarch proposal
in any way. I know one of the dpkg maintainers is even if not listed
in the wiki.
The steps below are features that must be added to apt/dpkg in order
to implement the maultiarch proposal. It is how the proposal says
multiarch will work. So if Tollef (or anyone for that matter) agrees
with the multiarch proposal they already agreed to the steps below.
>> - Adding support to libapt to download binary-<arch>/Packages for
>> multiple architectures and extending the sources.list format to
>> include [arch=i386] syntax.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536029
>>
>> If this is added then the ia32-apt-get, ia32-aptitude, ia32-synaptic
>> wrappers can stop running multiple instances of apt-get to update
>> the packages lists and use just Apt::Update::Post-Invoke. People
>> can keep the wrappers or create an /etc/apt.conf.d/ia32-apt-get
>> and use the plain versions.
>
> Is there any feedback from the apt maintainers on that? I cannot see
> anything in the bug report.
I talked with mvo on #debian-apt and he was open to including this
patch for the next experimental upload.
>> - Adding support in libapt / dpkg to support package:arch and allowing
>> libfoo:i386 and libfoo:amd64 to be coinstalled. Doesn't need
>> handling of /usr/share/* nor handling the Multi-Arch field nor all
>> the implicit package relationship magic multiarch involves.
>
> No bug report yet I assume? Is this already discussed with the
> appropriate maintainers?
Ask Steve Langasek. The multiarch proposal requires it and it is not
the job of ia32-libs-tools to implement multiarch. I can just take
advantage of it whenever apt/dpkg include this part of multiarch. The
specific implementation (libfoo:i386, libfoo\i386, libfoo/i386,
libfoo[i386], i386-libfoo, whatever) also doesn't matter. The concept
is important in whatever syntax it will be implemented. That is also
true for all the other steps. The concept behind each step matters and
I can adjust to whatever implementation apt/dpkg will adapt.
>> - Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in
>> individual packages.
>>
>> If this is done (like experimental wine has just done) then
>> ia32-libs-tools can stop moving files from /usr/lib to
>> /usr/lib32.
>
> This sounds non-breaking to me. Has this been discussed somewhere
> already? If so, how about doing "the usual" developer motivations,
> like a (dynamic) page which libraries need to be changed, plus lintian
> check? Do the glibc maintainers agree to change?
Eventual ALL library packages are supposed to change. As to which
"need" to change (first) depends on which libraries the user uses. The
ia32-libs and ia32-libs-gtk packages contain roughly the top 100
candidates. ia32-apt-get users use more.
The change is spelled out quite clearly in the multiarch proposal and
for a long time libc6 ships /etc/ld.so.conf.d/$(DEB_HOST_GNU_TYPE).conf
containing:
# Multiarch support
/lib/$(DEB_HOST_GNU_TYPE)
/usr/lib/$(DEB_HOST_GNU_TYPE)
So I assume they do agree. Iirc that was already supported in
old-stable. Certainly in stable.
But this really drifts off into an "implementing multiarch"
discussion, which this isn't about.
MfG
Goswin
Reply to: