Re: multiarch status update
#include <hallo.h>
* 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
> needed.
I don't see a bad problem with that, sounds like an acceptable
compromise.
> 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
> users.
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".
Eduard.
Reply to: