Pierre Habouzit <madco...@madism.org> writes:
> On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote:
>> Yannick <yannick.roeh...@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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
