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 Developerhttp://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
multiarch and maintainer scripts
Hi, 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. 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. 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. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Goswin von Brederlow goswin-...@web.de writes: 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. Surely this is as simple as: case `dpkg --print-architecture` in amd64) # Do some stuff. ;; i386) # Do some other stuff. ;; esac isn't it? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Russ Allbery r...@debian.org writes: Goswin von Brederlow goswin-...@web.de writes: 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. Surely this is as simple as: case `dpkg --print-architecture` in amd64) # Do some stuff. ;; i386) # Do some other stuff. ;; esac isn't it? That is another possibility. Is that the solution we (as in Debian) want? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Hi! On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote: Goswin von Brederlow goswin-...@web.de writes: 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? We discussed this with Steve some days ago. My initial idea was to make “dpkg --print-architecture” polymorphic, and change what it prints depending on what architecture the package being installed is. That would require less packaging changes, but it seems pretty fragile and non-obvious behaviour, and we have several packages using “uname -m”, they'd need to be changed due to this or just to multiarchify them anyway, so we discarded it. But yesterday I came up with a simpler and cleaner solution, just export an env var matching the package arch being installed. Something like DPKG_MAINTSCRIPT_ARCH or similar. 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. I don't think this example is relevant. Once libgl has been multiarchified, then everywhere the i386 file is going to be located under ‘/usr/lib/i486-linux-gnu/libGL.so.1.2’. Surely this is as simple as: case `dpkg --print-architecture` in amd64) # Do some stuff. ;; i386) # Do some other stuff. ;; esac isn't it? In this case it might have been enough, or not needed at all. But that would print the arch dpkg was built for (i.e. the native architecture), not the foreign arch of the package we are installing, which is what we'd be interested in most cases like grub, eglibc, module-init-tools or util-linux maint scripts. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Guillem Jover guil...@debian.org writes:
Hi!
On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote:
Goswin von Brederlow goswin-...@web.de writes:
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?
We discussed this with Steve some days ago. My initial idea was to
make âdpkg --print-architectureâ polymorphic, and change what it
prints depending on what architecture the package being installed is.
Then how would you detect if your package is unpacked on i386 or
amd64? An i386 deb knows at compile time that it is build for i386. I
see no good reason to have dpkg tell it so as well.
That would require less packaging changes, but it seems pretty
fragile and non-obvious behaviour, and we have several packages using
âuname -mâ, they'd need to be changed due to this or just to
multiarchify them anyway, so we discarded it.
uname -m tells what kernel is in use, not what architecture the
package was build for nor what architecture it gets installed for.
A mostly useless information. I would consider any package that uses
uname -m in its maintainer scrips buggy. You can not depend on it not
chaning at any time (the system is rebootet) and the mainatiner script
will not be rerun when it does.
But yesterday I came up with a simpler and cleaner solution, just
export an env var matching the package arch being installed. Something
like DPKG_MAINTSCRIPT_ARCH or similar.
That would be better, or at least not destroy other needed information.
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.
I don't think this example is relevant. Once libgl has been
multiarchified, then everywhere the i386 file is going to be located
under â/usr/lib/i486-linux-gnu/libGL.so.1.2â.
One can hope it catches on quickly enough. As it is free software it
can be changed easily enough. That might not always be the case,
especially when supporting backward compatible
/usr/lib{,32,64}/package/* plugin scanning though.
Surely this is as simple as:
case `dpkg --print-architecture` in
amd64)
# Do some stuff.
;;
i386)
# Do some other stuff.
;;
esac
isn't it?
In this case it might have been enough, or not needed at all.
But that would print the arch dpkg was built for (i.e. the native
architecture), not the foreign arch of the package we are installing,
which is what we'd be interested in most cases like grub, eglibc,
module-init-tools or util-linux maint scripts.
Which is what was required.
The package always knows the arch it build for at build time. For that
one can use
PKG_ARCH=@DEB_HOST_ARCH@
and
sed 's/@DEB_HOST_ARCH@/$(DEB_HOST_ARCH)/g' postinst.in postinst
or have debian/package.postinst.i386 and debian/package.postinst.amd64
and debhelper install the right one and so on.
(which doesn't mean dpkg exporting the arch at configure time wouldn't
be better in some cases)
regards,
guillem
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
