On Thu, Jul 02, 2009 at 09:36:23PM +0200, Goswin von Brederlow wrote: > what can be done if the maintainer scripts of a package must behave > differently when unpacking the i386 deb on i386 or the i386 deb on > amd64?
> For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on > i386 but /usr/lib32/libGL.so.1.2 on amd64. This example would seem to be obsolete once mesa was converted to multiarch paths. We could simply guarantee that /usr/lib32/libGL.so.1.2 didn't exist on any affected system (using versioned conflicts if appropriate), and then there's no need to distinguish. > Other examples would be packages that scan for plugins in their > postinst to generate a list of them. Pango and gtk used to do > that. Even if they are changed the multiarch library dirs they should > probably continue to scan the old plugin dirs for backward > compatibility. "used to do" - are there real-world examples of this? I don't think we should engineer solutions that are only relevant for *hypothetical* backwards compatibility. > So would it make sense to allow architecture specific maintainer > scripts? Back to the fglrx-glx example the control.tar.gz could > contain: > preinst-amd64 - use when configuring on amd64 > preinst - use otherwise > I choose '-' so it doesn't collide with debhelpers preinst.amd64 > source files. I think this is a horribly inelegant solution. And I'm unconvinced that there's any real reason at all for a properly implemented multiarch package to try to distinguish between different host architectures. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org