Re: multiarch status update
* Goswin von Brederlow [Tue, May 16 2006, 11:55:18PM]:
> What do you mean with invasive? Multiarch is designed to be
> implemented without disrupting the existing archive or mono-arch
> systems at any time. Each package can get converted to multiarch by
> itself and once a substantial number of packages have done so a
> multiarch dpkg/apt/aptitude can be used.
And that is why I question it. Do we need that? You demonstrated that it
is quite easy to setup the depencency chain for a package... but why
should we care about change the whole distribution for the sake of few
3rd party packages if we have sufficient workarounds?
> But cooking the packages is not 100% successfull and involves a lot of
> diversions and alternatives. Every include file gets diverted, every
> binary in a library gets an alternative. All cooked packages depend on
> their uncooked other architecture version for pre/postinst/rm scripts,
> forcing both arch to be installed even if only the cooked one is
I don't see a bad problem with that, sounds like an acceptable
> And still some things won't work without the multiarch dirs being used
> by any software using dlopen and similar. That includes X locales,
> gtk-pixmap, pango to start with.
Such things are not okay but there could be few workarounds as well.
> It works for a stable release but for unstable the constant stream of
> changes needed in the cooking script would be very disruptive for
Only if you port the whole distribution. If you port few dozens of
library packages, maintaining them should be feasible.
> It also is disruptive to building packages. Build-Depends will only
> work for the native arch and not for the cooked packages and
> building for the cooked arch will give precooked Depends (I do cook
> shlibs files) so they are invalid for uploads.
This problem is only implied by "porting the whole arch and using
everything like a native package".