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

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

> 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".


Reply to: