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

Re: ia32-libs{-tools}, multiarch, squeeze

Pierre Habouzit <madcoder@madism.org> writes:

> On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote:
>> Yannick <yannick.roehlly@free.fr> writes:
>> > Goswin von Brederlow wrote:
>> >
>> >> And hey, the "good" reason was "diverting the package management tools
>> >> is unacceptable". But, no, we have to do insults instead of arguing.
>> >
>> > Alas, despite the diversion of the package management tools, I find ia32-
>> > apt-get pretty useful.
>> >
>> > For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian 
>> > (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). 
>> > With ia32-apt-get, I could install the 32bit version of my GTK theme engine 
>> > so that Firefox can look good.
>> >
>> > Is there a design problem in converting 32bits libraries to ia32-* packages 
>> > or the sole problem is the diversion of apt-get and co?
>> There where 3 minor bug reports about an ia32-* package not working
>> right. Out of an estimate of 160-200 packages people use. I think that
>> is pretty good. All 3 bugs where fix in a subsequent upload and
>> currently there are no reported missconversions. On the other hand ~45
>> bugs about missconversion or missing packages in the old ia32-libs
>> where closed (and will have to be reopened now). So I don't believe
>> there is a design problem there. That part works just fine.
>> But the diversions had people totaly in outrage. So much so that I
>> believe they didn't even look past that at all.
> You absolutely don't get it do you ? Your conversion system is an ugly
> hack, something completely horrible, that is meant to break in horrible
> ways, has no forward upgrate path to a multiarch work, and so on.

The conversion system is an ugly hack. Sure. But it is the same ugly
hack 32bit support has always done, for over 5 years. The only change
is when the conversion is done, i.e. moved from the buildd to the
users system. By moving it there only those things the user
needs/wants need converting and all the user needs/wants can be
converted. That is the big advantage of ia32-apt-get over ia32-libs.
If you find the conversion unacceptable then the only option for you
is to request 32bit support on amd64/ia64 is removed till multiarch.

The upgrade path to multiarch is for the multiarch i386 deb to
Conflicts/Replaces: <package that contains the same files>. Which
means ia32-libs or ia32-libs-gtk for the old system or ia32-<package>
for the ia32-apt-get one. And again with ia32-apt-get there is a huge
advantage. As packages convert to multiarch they can be droped in
ia32-apt-get on a case by case basis and replaced by the multiarch
one. Meaning users don't have to wait for and update 200 packages in a
single step.

> If you really mean to provide something like ia32-apt-get, what you
> ought to do is to:
>   - help the user create and maintain a proper 32bits chroot;

Way to complex and fragile with the millions of possible
configurations of users systems.

>   - let ia32-apt-get or whatever it's called be a forward to running
>     apt-get inside that chroot;
>   - find a way to let the user run commands from that chroot seamlessly.

Impossible to make that work for everyone/everything. Any solution
will be a special case solution and only support some configurations.

> That would be totally acceptable, and probably an improvement over the
> current situation.


Reply to: