Re: multiarch and maintainer scripts
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: