How to convince APT that a cross-arch package is installed manually?
I have a qemu-armhf chroot environment on an amd64 machine (it's mainly for compiling Raspberry Pi code). As such it can run both armhf and amd64 binaries but it's faster doing the latter.
There are certain packages (such as make) where I've installed the amd64 version inside the chroot in order to get better speed. That works well up until I need to apt-get some other armhf package and it happens to have make listed as a dependency, whereupon I get this:
The following packages have unmet dependencies:
build-essential : Depends: make but it is not going to be installed
dpkg-dev : Depends: make but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
If I try the suggested command, then it says it wants to install make:armhf
and uninstall make:amd64
. I don't want it to do that. How do I tell APT that make:armhf
is already installed (because I want it to use make:amd64
to satisfy dependencies) without actually installing it?
I've tried using apt-mark manual make
but it says that it is not installed.
I know this probably isn't the right way to do it, but I've been looking at the /var/lib/dpkg/status
file to try to work out how it thinks the package definitions work and to try to trick it into agreeing that make:amd64 satisfies make:armhf as well.
In particular I noticed that "libbz2-1.0" is a package that's listed as installed twice; once as:
Architecture: armhf
Multi-Arch: same
Pre-Depends: multiarch-support
and once as:
Architecture: amd64
Multi-Arch: foreign
Pre-Depends: multiarch-support
So I tried duplicating the entries for "make" similarly, setting all of those values above. But now APT's just saying that "make" and "make:amd64" are conflicted. Why is it a conflict when make does it but not when libbz2-1.0 does it? (I hope it's not special-casing libraries; that seems like it should be a bug.)
Per this answer, I tried building a dummy package with equivs
and installing that (after removing my manual fiddling above), but installing it produces these errors:
# dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make)
# dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above)
Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ...
Unpacking replacement make ...
dpkg: dependency problems prevent configuration of make:
make depends on make:amd64 (= 3.81-8.2).
So again the problem looks like it thinks make:armhf is a replacement for make:amd64, and I don't know how to tell it that I want these two packages to coexist. (It doesn't seem to have a problem with the idea of two libbz2 packages coexisting, for example.)
debian apt cross-compilation multiarch
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have a qemu-armhf chroot environment on an amd64 machine (it's mainly for compiling Raspberry Pi code). As such it can run both armhf and amd64 binaries but it's faster doing the latter.
There are certain packages (such as make) where I've installed the amd64 version inside the chroot in order to get better speed. That works well up until I need to apt-get some other armhf package and it happens to have make listed as a dependency, whereupon I get this:
The following packages have unmet dependencies:
build-essential : Depends: make but it is not going to be installed
dpkg-dev : Depends: make but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
If I try the suggested command, then it says it wants to install make:armhf
and uninstall make:amd64
. I don't want it to do that. How do I tell APT that make:armhf
is already installed (because I want it to use make:amd64
to satisfy dependencies) without actually installing it?
I've tried using apt-mark manual make
but it says that it is not installed.
I know this probably isn't the right way to do it, but I've been looking at the /var/lib/dpkg/status
file to try to work out how it thinks the package definitions work and to try to trick it into agreeing that make:amd64 satisfies make:armhf as well.
In particular I noticed that "libbz2-1.0" is a package that's listed as installed twice; once as:
Architecture: armhf
Multi-Arch: same
Pre-Depends: multiarch-support
and once as:
Architecture: amd64
Multi-Arch: foreign
Pre-Depends: multiarch-support
So I tried duplicating the entries for "make" similarly, setting all of those values above. But now APT's just saying that "make" and "make:amd64" are conflicted. Why is it a conflict when make does it but not when libbz2-1.0 does it? (I hope it's not special-casing libraries; that seems like it should be a bug.)
Per this answer, I tried building a dummy package with equivs
and installing that (after removing my manual fiddling above), but installing it produces these errors:
# dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make)
# dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above)
Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ...
Unpacking replacement make ...
dpkg: dependency problems prevent configuration of make:
make depends on make:amd64 (= 3.81-8.2).
So again the problem looks like it thinks make:armhf is a replacement for make:amd64, and I don't know how to tell it that I want these two packages to coexist. (It doesn't seem to have a problem with the idea of two libbz2 packages coexisting, for example.)
debian apt cross-compilation multiarch
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12
add a comment |
I have a qemu-armhf chroot environment on an amd64 machine (it's mainly for compiling Raspberry Pi code). As such it can run both armhf and amd64 binaries but it's faster doing the latter.
There are certain packages (such as make) where I've installed the amd64 version inside the chroot in order to get better speed. That works well up until I need to apt-get some other armhf package and it happens to have make listed as a dependency, whereupon I get this:
The following packages have unmet dependencies:
build-essential : Depends: make but it is not going to be installed
dpkg-dev : Depends: make but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
If I try the suggested command, then it says it wants to install make:armhf
and uninstall make:amd64
. I don't want it to do that. How do I tell APT that make:armhf
is already installed (because I want it to use make:amd64
to satisfy dependencies) without actually installing it?
I've tried using apt-mark manual make
but it says that it is not installed.
I know this probably isn't the right way to do it, but I've been looking at the /var/lib/dpkg/status
file to try to work out how it thinks the package definitions work and to try to trick it into agreeing that make:amd64 satisfies make:armhf as well.
In particular I noticed that "libbz2-1.0" is a package that's listed as installed twice; once as:
Architecture: armhf
Multi-Arch: same
Pre-Depends: multiarch-support
and once as:
Architecture: amd64
Multi-Arch: foreign
Pre-Depends: multiarch-support
So I tried duplicating the entries for "make" similarly, setting all of those values above. But now APT's just saying that "make" and "make:amd64" are conflicted. Why is it a conflict when make does it but not when libbz2-1.0 does it? (I hope it's not special-casing libraries; that seems like it should be a bug.)
Per this answer, I tried building a dummy package with equivs
and installing that (after removing my manual fiddling above), but installing it produces these errors:
# dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make)
# dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above)
Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ...
Unpacking replacement make ...
dpkg: dependency problems prevent configuration of make:
make depends on make:amd64 (= 3.81-8.2).
So again the problem looks like it thinks make:armhf is a replacement for make:amd64, and I don't know how to tell it that I want these two packages to coexist. (It doesn't seem to have a problem with the idea of two libbz2 packages coexisting, for example.)
debian apt cross-compilation multiarch
I have a qemu-armhf chroot environment on an amd64 machine (it's mainly for compiling Raspberry Pi code). As such it can run both armhf and amd64 binaries but it's faster doing the latter.
There are certain packages (such as make) where I've installed the amd64 version inside the chroot in order to get better speed. That works well up until I need to apt-get some other armhf package and it happens to have make listed as a dependency, whereupon I get this:
The following packages have unmet dependencies:
build-essential : Depends: make but it is not going to be installed
dpkg-dev : Depends: make but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
If I try the suggested command, then it says it wants to install make:armhf
and uninstall make:amd64
. I don't want it to do that. How do I tell APT that make:armhf
is already installed (because I want it to use make:amd64
to satisfy dependencies) without actually installing it?
I've tried using apt-mark manual make
but it says that it is not installed.
I know this probably isn't the right way to do it, but I've been looking at the /var/lib/dpkg/status
file to try to work out how it thinks the package definitions work and to try to trick it into agreeing that make:amd64 satisfies make:armhf as well.
In particular I noticed that "libbz2-1.0" is a package that's listed as installed twice; once as:
Architecture: armhf
Multi-Arch: same
Pre-Depends: multiarch-support
and once as:
Architecture: amd64
Multi-Arch: foreign
Pre-Depends: multiarch-support
So I tried duplicating the entries for "make" similarly, setting all of those values above. But now APT's just saying that "make" and "make:amd64" are conflicted. Why is it a conflict when make does it but not when libbz2-1.0 does it? (I hope it's not special-casing libraries; that seems like it should be a bug.)
Per this answer, I tried building a dummy package with equivs
and installing that (after removing my manual fiddling above), but installing it produces these errors:
# dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make)
# dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above)
Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ...
Unpacking replacement make ...
dpkg: dependency problems prevent configuration of make:
make depends on make:amd64 (= 3.81-8.2).
So again the problem looks like it thinks make:armhf is a replacement for make:amd64, and I don't know how to tell it that I want these two packages to coexist. (It doesn't seem to have a problem with the idea of two libbz2 packages coexisting, for example.)
debian apt cross-compilation multiarch
debian apt cross-compilation multiarch
edited Apr 13 '17 at 12:36
Community♦
1
1
asked Aug 11 '14 at 7:57
MiralMiral
1565
1565
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12
add a comment |
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12
add a comment |
1 Answer
1
active
oldest
votes
I haven't played much with multiarch systems, so there may well be a better way than what I'm proposing here. I haven't tested my proposal, I'm not sure that it doesn't run against some peculiarity of multiarch.
You can use equivs to create dummy packages for dependencies only.
- Create a control file with
equivs-control make.control
- Edit the control file: set
Package: make
,Architecture: armhf
,Depends: make:amd64
, andMulti-Arch: foreign
. You may want to setVersion
to match the amd64 make version as well. - Create the dummy package:
equivs-build make.control
- Install the dummy package in the chroot
If this doesn't satisfy dpkg, a different approach that will work but is less convenient is to not install the amd64 make inside the chroot, but instead make the host root available inside the chroot (with a bind mount, see Providing /bin and /lib inside a chroot jail for examples), or at least the make
binary and its dependencies (which for make
is just libc). Add the directory where the binary is mounted to the PATH. Create a dummy package as above, but just declare make
as installed, don't put any Depends
or Multi-Arch
header.
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
@Miral Hmmm. Does it help if you addMulti-Arch: foreign
to the dummy package? But now that I think of it, the nativemake
package probably needs aMulti-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64make
package` have that header? If it doesn't, then tweaking/var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.
– Gilles
Aug 12 '14 at 9:11
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f149617%2fhow-to-convince-apt-that-a-cross-arch-package-is-installed-manually%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I haven't played much with multiarch systems, so there may well be a better way than what I'm proposing here. I haven't tested my proposal, I'm not sure that it doesn't run against some peculiarity of multiarch.
You can use equivs to create dummy packages for dependencies only.
- Create a control file with
equivs-control make.control
- Edit the control file: set
Package: make
,Architecture: armhf
,Depends: make:amd64
, andMulti-Arch: foreign
. You may want to setVersion
to match the amd64 make version as well. - Create the dummy package:
equivs-build make.control
- Install the dummy package in the chroot
If this doesn't satisfy dpkg, a different approach that will work but is less convenient is to not install the amd64 make inside the chroot, but instead make the host root available inside the chroot (with a bind mount, see Providing /bin and /lib inside a chroot jail for examples), or at least the make
binary and its dependencies (which for make
is just libc). Add the directory where the binary is mounted to the PATH. Create a dummy package as above, but just declare make
as installed, don't put any Depends
or Multi-Arch
header.
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
@Miral Hmmm. Does it help if you addMulti-Arch: foreign
to the dummy package? But now that I think of it, the nativemake
package probably needs aMulti-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64make
package` have that header? If it doesn't, then tweaking/var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.
– Gilles
Aug 12 '14 at 9:11
add a comment |
I haven't played much with multiarch systems, so there may well be a better way than what I'm proposing here. I haven't tested my proposal, I'm not sure that it doesn't run against some peculiarity of multiarch.
You can use equivs to create dummy packages for dependencies only.
- Create a control file with
equivs-control make.control
- Edit the control file: set
Package: make
,Architecture: armhf
,Depends: make:amd64
, andMulti-Arch: foreign
. You may want to setVersion
to match the amd64 make version as well. - Create the dummy package:
equivs-build make.control
- Install the dummy package in the chroot
If this doesn't satisfy dpkg, a different approach that will work but is less convenient is to not install the amd64 make inside the chroot, but instead make the host root available inside the chroot (with a bind mount, see Providing /bin and /lib inside a chroot jail for examples), or at least the make
binary and its dependencies (which for make
is just libc). Add the directory where the binary is mounted to the PATH. Create a dummy package as above, but just declare make
as installed, don't put any Depends
or Multi-Arch
header.
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
@Miral Hmmm. Does it help if you addMulti-Arch: foreign
to the dummy package? But now that I think of it, the nativemake
package probably needs aMulti-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64make
package` have that header? If it doesn't, then tweaking/var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.
– Gilles
Aug 12 '14 at 9:11
add a comment |
I haven't played much with multiarch systems, so there may well be a better way than what I'm proposing here. I haven't tested my proposal, I'm not sure that it doesn't run against some peculiarity of multiarch.
You can use equivs to create dummy packages for dependencies only.
- Create a control file with
equivs-control make.control
- Edit the control file: set
Package: make
,Architecture: armhf
,Depends: make:amd64
, andMulti-Arch: foreign
. You may want to setVersion
to match the amd64 make version as well. - Create the dummy package:
equivs-build make.control
- Install the dummy package in the chroot
If this doesn't satisfy dpkg, a different approach that will work but is less convenient is to not install the amd64 make inside the chroot, but instead make the host root available inside the chroot (with a bind mount, see Providing /bin and /lib inside a chroot jail for examples), or at least the make
binary and its dependencies (which for make
is just libc). Add the directory where the binary is mounted to the PATH. Create a dummy package as above, but just declare make
as installed, don't put any Depends
or Multi-Arch
header.
I haven't played much with multiarch systems, so there may well be a better way than what I'm proposing here. I haven't tested my proposal, I'm not sure that it doesn't run against some peculiarity of multiarch.
You can use equivs to create dummy packages for dependencies only.
- Create a control file with
equivs-control make.control
- Edit the control file: set
Package: make
,Architecture: armhf
,Depends: make:amd64
, andMulti-Arch: foreign
. You may want to setVersion
to match the amd64 make version as well. - Create the dummy package:
equivs-build make.control
- Install the dummy package in the chroot
If this doesn't satisfy dpkg, a different approach that will work but is less convenient is to not install the amd64 make inside the chroot, but instead make the host root available inside the chroot (with a bind mount, see Providing /bin and /lib inside a chroot jail for examples), or at least the make
binary and its dependencies (which for make
is just libc). Add the directory where the binary is mounted to the PATH. Create a dummy package as above, but just declare make
as installed, don't put any Depends
or Multi-Arch
header.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Aug 12 '14 at 1:11
GillesGilles
543k12811001618
543k12811001618
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
@Miral Hmmm. Does it help if you addMulti-Arch: foreign
to the dummy package? But now that I think of it, the nativemake
package probably needs aMulti-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64make
package` have that header? If it doesn't, then tweaking/var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.
– Gilles
Aug 12 '14 at 9:11
add a comment |
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
@Miral Hmmm. Does it help if you addMulti-Arch: foreign
to the dummy package? But now that I think of it, the nativemake
package probably needs aMulti-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64make
package` have that header? If it doesn't, then tweaking/var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.
– Gilles
Aug 12 '14 at 9:11
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
Unfortunately this bug still seems to be a thing. (I'm getting the same error, from an Ubuntu 14.04 host.)
– Miral
Aug 12 '14 at 1:34
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
wouldn't having the package depends on another package with the same name create a dependency cycle it can't satisfy?
– pqnet
Aug 12 '14 at 2:54
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
It ought to be able to satisfy it, since they're different architectures. But apparently yes, this makes it unhappy. See my updated question.
– Miral
Aug 12 '14 at 3:22
1
1
@Miral Hmmm. Does it help if you add
Multi-Arch: foreign
to the dummy package? But now that I think of it, the native make
package probably needs a Multi-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64 make
package` have that header? If it doesn't, then tweaking /var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.– Gilles
Aug 12 '14 at 9:11
@Miral Hmmm. Does it help if you add
Multi-Arch: foreign
to the dummy package? But now that I think of it, the native make
package probably needs a Multi-Arch
field, otherwise dpkg will assume that the package doesn't support multiarch. Does your amd64 make
package` have that header? If it doesn't, then tweaking /var/lib/dpkg/status
would probably do the trick, but of course that's lost on upgrade. See my edit for a less convenient approach.– Gilles
Aug 12 '14 at 9:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f149617%2fhow-to-convince-apt-that-a-cross-arch-package-is-installed-manually%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Make is a binary, multiarch won't install two binary files of different arch in same filename. "The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths)." wiki.debian.org/Multiarch
– umeboshi
Jan 26 '15 at 3:02
That's fine, I only really want one version installed (the amd64 version). The problem is that I also want to be able to install armhf library packages that depend on the armhf version of make instead of "any runnable make". (Or to rephrase, the problem is that the libraries do not depend on "any make", they depend on "my-arch make".)
– Miral
Jan 26 '15 at 23:30
Is there something preventing you from using a cross-compile toolchain?
– umeboshi
Jan 27 '15 at 0:12
FWIW, I've been staying away from multiarch and using schroot, etc.
– umeboshi
Jan 27 '15 at 0:15
The packages I'm trying to build aren't really cross-compile-friendly; they assume they can build and run things using the same compiler for host and target. Additionally it's convenient to use apt tools with the same repositories to ensure that I'm building against the same versions of libraries as will be installed on the target. But as mentioned above one of the tricks that I'm trying to use to improve performance is to install the cross compiler as the "native" compiler inside the chroot, so it's faster.
– Miral
Jan 27 '15 at 1:12