Summary: | app-arch/dpkg bootstrap problem breaks dpkg-architecture | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fiona Klute <fiona.klute> |
Component: | Current packages | Assignee: | Debian-related package maintainers [DISBANDED] <deb-tools+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | java |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 266733 | ||
Attachments: |
Set $pkgdatadir to srcdir in configure
Do the previous thing and also FIX the FIXME in Arch.pm |
Description
Fiona Klute
2009-10-14 19:53:25 UTC
That's quite funny actually. So the steps to reproduce would go like this: emerge -C dpkg; emerge dpkg && dpkg-architecture (In reply to comment #0) > The value returned by "dpkg --print-architecture" is set at configure-time by > calling the to-be-installed dpkg-architecture (see m4/arch.m4 in the dpkg > source). This doesn't work properly if dpkg is not available (see FIXME > comment in sub get_raw_build_arch() in the Dpkg::Arch module). The real question is, why /does/ it work the second time? What has in the mean time put the information in the right place for the second emerge to install a useful program after all? Is it as simple as fixing the path where the script is found in the ./configure script? Or the paths to ostable, cputable and so on? > I was able to reproduce the bug with dpkg 1.15.2 and 1.15.4. It is probably > safe to assume that it applies to 1.15.3 and 1.15.3.1 as well. All versions in the tree suffer this problem. Luckily, only few packages in the tree use dpkg-architecture. :) Created attachment 218489 [details, diff]
Set $pkgdatadir to srcdir in configure
Good you give this patch a spin, please? I am thinking about preparing a similar configure.ac patch (in m4/dpkg-arch.m4 that is) that $upstream might want.
Comment on attachment 218489 [details, diff]
Set $pkgdatadir to srcdir in configure
No, this isn't in itself going to work. Even the m4 version I prepared would fail because in its ultimate wisdom, dpkg-architecture ends up calling `dpkg --print-architecture', which, hey, isn't installed yet, and worse still, isn't built yet at ./configure time. :-\
Created attachment 218499 [details, diff]
Do the previous thing and also FIX the FIXME in Arch.pm
The additional patch in this file simply makes sure that when dpkg isn't found, DEB_BUILD_ARCH equals DEB_HOST_ARCH. Please try it out.
With the patch, you should now see something like: astrid ~ # emerge -C dpkg; emerge -v dpkg && dpkg-architecture [...] >>> /etc/dpkg/ >>> /etc/dpkg/dpkg.cfg.d/ >>> /etc/dpkg/dselect.cfg.d/ >>> /etc/alternatives/ >>> /etc/alternatives/README >>> Regenerating /etc/ld.so.cache... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=i386 DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu Or more conveniently, try dpkg-1.15.5.6-r1 which is in the tree now to specifically solve this issue. Reopen this bug report if it turns out to be unsatisfactory. app-arch/dpkg-1.15.5.6-r1 works after a fresh install, thanks. |