#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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
