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

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: