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
