Re: Improve support for installing 32-bit libraries on 64-bit systems
2010/6/26 Luca Bruno <lucab@debian.org>:
> David Kalnischkies scrisse:
>> The biggest showstoppers are as far as i know that
>> a) dpkg doesn't support it
>> b) APT doesn't support it
>> c) (not many) packages use it (last time i check ~24)
>>
>> c) is likely caused by a) and b) which in fact decreases the
>> motivation for a) and b) to implement it as nobody use it… ***
>> dependency loop detected ***
>
> Goswin recently offered some help to improve the situation regarding a)
> and c) points, but I've seen no (public) answer from you:
> http://lists.debian.org/debian-devel/2010/04/msg00493.html
What should i have answered? That i like that he wants to work
on a) and c)? I knew that as we exchanged a few mails already
as he is also present on deity@ and the associated bugreports,
so my only semi-public move as response to this mail was to join
the recommend list and proceed in doing "stuff" rather than writing
the obvious… especially as i was not a (direct) addressee of the mail
and got it a bit later than usual.
I can't comment on a) as dpkg is magic (for me at least) and the problem
for dpkg is more about reference counting for /usr/share/doc files than
dependency solving as far as i understand and should as it is promised be
done by someone who know his stuff. It might need to do something similar
to what i did in APT with creating pseudo-archdepending packages for
arch:all packages to "simplify" dependency solving, for their dependency
checking but that depends on their liking, isn't limited by compatibility
requirements like it is in APT - and the theory is documented in
README.MultiArch and code in case i am hit by a bus,
so as long as nobody has (further) questions - nothing to comment…
c) is also not my cup of tea so far as i never touched a library by now,
starting to tell libary maintainers they should do this and that is at least
in my understanding a bit awkward then. (This avoids also a bit pre-seeding
everyone with my understanding.) ;)
> Given that you say apt in experimental is semi-working, it would be
> interesting to join forces and see if something almost test-able can
> be provided.
Semi working as (obviously) nothing can be really installed as dpkg
will jump at you if you try. Semi working also as i focused mostly
on the case until now that you have e.g. i386 and amd64 packages
available but have only packages from one arch installed
(fun-fact: It is i386 for me as i have no amd64 system currently).
Requesting to install one or two packages from the other arch will be
the most seen use case and this works so far, but only with simple
constructed cases as in real world you will be hit by c) - i see that
positive as this at least guarantees that APT isn't too relaxed about
the dependencies. ;)
The ABI changes for it are quite stable and i am especially happy that
they are API compatible to the SingleArch-epoch.
The APT part left is beside bughunting really the (important) MultiArch
"auxiliary" stuff i described in the proposal.
> If so, it would also be useful to advertise it a bit more and hoping to
> gain some momentum...
While many would certainly love it, i don't feel like rushing into a mess.
We already saw some tries to implement a semi-multiarch behavior
and personally i don't want to see them again. Do it once, clean and
for real - and at best not before squeeze freeze or even release:
It requires a lot of changes to work correctly in a lot of packages and
mindsets and would be currently a waste of time which could better be
spent in (rc-)bugs and ongoing or waiting transitions.
(At least in the eyes of my mentor and myself. Big bangs after releases
generally generate more (positive) noise than near freeze time)
And most of the auxiliary stuff has the advantage to be not only "needed"
for MultiArch, but fixes a lot of bugs in drive-by mode.
Thankfully APT has still so many of them to choose from. ;)
Best regards,
David Kalnischkies
Reply to: