Building .deb on Alpine

Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I'm very new to Linux overall and I'm trying to find a way to build a Debian package on an Alpine docker image. It is by far the fastest I can get my pipeline to run, but unfortunately when I try to run dpkg-deb --build I get the following error:
03:22:44 dpkg-deb: building package 'x-sync' in 'x-sync_1.0.2.deb'.
03:22:44 tar: unrecognized option: format=gnu
03:22:44 BusyBox v1.27.2 (2018-01-29 15:48:57 GMT) multi-call binary.
03:22:44
03:22:44 Usage: tar -[cxtZzJjahmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
03:22:44
03:22:44 Create, extract, or list files from a tar file
03:22:44
03:22:44 Operation:
03:22:44 c Create
03:22:44 x Extract
03:22:44 t List
03:22:44 f Name of TARFILE ('-' for stdin/out)
03:22:44 C Change to DIR before operation
03:22:44 v Verbose
03:22:44 Z (De)compress using compress
03:22:44 z (De)compress using gzip
03:22:44 J (De)compress using xz
03:22:44 j (De)compress using bzip2
03:22:44 a (De)compress using lzma
03:22:44 O Extract to stdout
03:22:44 h Follow symlinks
03:22:44 m Don't restore mtime
03:22:44 exclude File to exclude
03:22:44 X File with names to exclude
03:22:44 T File with names to include
03:22:44 dpkg-deb: error: subprocess tar -cf returned error exit status 1
I attempted the packaging on the following Dockerfile:
FROM alpine
RUN apk add --no-cache dpkg openjdk8
Is there any way to build a Debian package on this distro that would be cross compatible with other distros, e.g. my Ubuntu dev environment?
debian dpkg alpine-linux
add a comment |Â
up vote
0
down vote
favorite
I'm very new to Linux overall and I'm trying to find a way to build a Debian package on an Alpine docker image. It is by far the fastest I can get my pipeline to run, but unfortunately when I try to run dpkg-deb --build I get the following error:
03:22:44 dpkg-deb: building package 'x-sync' in 'x-sync_1.0.2.deb'.
03:22:44 tar: unrecognized option: format=gnu
03:22:44 BusyBox v1.27.2 (2018-01-29 15:48:57 GMT) multi-call binary.
03:22:44
03:22:44 Usage: tar -[cxtZzJjahmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
03:22:44
03:22:44 Create, extract, or list files from a tar file
03:22:44
03:22:44 Operation:
03:22:44 c Create
03:22:44 x Extract
03:22:44 t List
03:22:44 f Name of TARFILE ('-' for stdin/out)
03:22:44 C Change to DIR before operation
03:22:44 v Verbose
03:22:44 Z (De)compress using compress
03:22:44 z (De)compress using gzip
03:22:44 J (De)compress using xz
03:22:44 j (De)compress using bzip2
03:22:44 a (De)compress using lzma
03:22:44 O Extract to stdout
03:22:44 h Follow symlinks
03:22:44 m Don't restore mtime
03:22:44 exclude File to exclude
03:22:44 X File with names to exclude
03:22:44 T File with names to include
03:22:44 dpkg-deb: error: subprocess tar -cf returned error exit status 1
I attempted the packaging on the following Dockerfile:
FROM alpine
RUN apk add --no-cache dpkg openjdk8
Is there any way to build a Debian package on this distro that would be cross compatible with other distros, e.g. my Ubuntu dev environment?
debian dpkg alpine-linux
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine tobitnami/minideband it works, as expected. So if I understand you right I shouldn't bother?
â hochas
Jun 15 at 7:12
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm very new to Linux overall and I'm trying to find a way to build a Debian package on an Alpine docker image. It is by far the fastest I can get my pipeline to run, but unfortunately when I try to run dpkg-deb --build I get the following error:
03:22:44 dpkg-deb: building package 'x-sync' in 'x-sync_1.0.2.deb'.
03:22:44 tar: unrecognized option: format=gnu
03:22:44 BusyBox v1.27.2 (2018-01-29 15:48:57 GMT) multi-call binary.
03:22:44
03:22:44 Usage: tar -[cxtZzJjahmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
03:22:44
03:22:44 Create, extract, or list files from a tar file
03:22:44
03:22:44 Operation:
03:22:44 c Create
03:22:44 x Extract
03:22:44 t List
03:22:44 f Name of TARFILE ('-' for stdin/out)
03:22:44 C Change to DIR before operation
03:22:44 v Verbose
03:22:44 Z (De)compress using compress
03:22:44 z (De)compress using gzip
03:22:44 J (De)compress using xz
03:22:44 j (De)compress using bzip2
03:22:44 a (De)compress using lzma
03:22:44 O Extract to stdout
03:22:44 h Follow symlinks
03:22:44 m Don't restore mtime
03:22:44 exclude File to exclude
03:22:44 X File with names to exclude
03:22:44 T File with names to include
03:22:44 dpkg-deb: error: subprocess tar -cf returned error exit status 1
I attempted the packaging on the following Dockerfile:
FROM alpine
RUN apk add --no-cache dpkg openjdk8
Is there any way to build a Debian package on this distro that would be cross compatible with other distros, e.g. my Ubuntu dev environment?
debian dpkg alpine-linux
I'm very new to Linux overall and I'm trying to find a way to build a Debian package on an Alpine docker image. It is by far the fastest I can get my pipeline to run, but unfortunately when I try to run dpkg-deb --build I get the following error:
03:22:44 dpkg-deb: building package 'x-sync' in 'x-sync_1.0.2.deb'.
03:22:44 tar: unrecognized option: format=gnu
03:22:44 BusyBox v1.27.2 (2018-01-29 15:48:57 GMT) multi-call binary.
03:22:44
03:22:44 Usage: tar -[cxtZzJjahmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
03:22:44
03:22:44 Create, extract, or list files from a tar file
03:22:44
03:22:44 Operation:
03:22:44 c Create
03:22:44 x Extract
03:22:44 t List
03:22:44 f Name of TARFILE ('-' for stdin/out)
03:22:44 C Change to DIR before operation
03:22:44 v Verbose
03:22:44 Z (De)compress using compress
03:22:44 z (De)compress using gzip
03:22:44 J (De)compress using xz
03:22:44 j (De)compress using bzip2
03:22:44 a (De)compress using lzma
03:22:44 O Extract to stdout
03:22:44 h Follow symlinks
03:22:44 m Don't restore mtime
03:22:44 exclude File to exclude
03:22:44 X File with names to exclude
03:22:44 T File with names to include
03:22:44 dpkg-deb: error: subprocess tar -cf returned error exit status 1
I attempted the packaging on the following Dockerfile:
FROM alpine
RUN apk add --no-cache dpkg openjdk8
Is there any way to build a Debian package on this distro that would be cross compatible with other distros, e.g. my Ubuntu dev environment?
debian dpkg alpine-linux
asked Jun 15 at 6:45
hochas
1033
1033
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine tobitnami/minideband it works, as expected. So if I understand you right I shouldn't bother?
â hochas
Jun 15 at 7:12
add a comment |Â
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine tobitnami/minideband it works, as expected. So if I understand you right I shouldn't bother?
â hochas
Jun 15 at 7:12
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine to
bitnami/minideb and it works, as expected. So if I understand you right I shouldn't bother?â hochas
Jun 15 at 7:12
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine to
bitnami/minideb and it works, as expected. So if I understand you right I shouldn't bother?â hochas
Jun 15 at 7:12
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
The best environment in which to build Debian packages is always a Debian-based environment. While Alpine-based containers are nice because of their small size and fast setup times, they introduce a number of issues, two of which are particularly troublesome:
- they use Busybox, where Debian packages rely on the GNU variants of most tools (e.g.
taras you discovered); - most importantly, they use musl, where Debian defaults to glibc.
Both of these can be worked around, but by the time you do that youâÂÂve lost the advantage of a small Alpine container, compared to a minimal Debian container (such as bitnami/minideb as you mentioned).
Note that if youâÂÂre running a Debian derivative on your development and/or build systems, you can skip the container stage entirely, while still using a contained build environment, by using pbuilder. For maximum speed, mount a tmpfs on /var/cache/pbuilder/build, and run the build with eatmydata. sbuild and cowbuilder are also worth looking into, especially if you regularly build similar packages.
As an aside, instead of building binary packages using dpkg-deb -b, I highly recommend learning how to build source packages; start with Vincent BernatâÂÂs pragmatic Debian packaging, itâÂÂs nice and easy.
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
The best environment in which to build Debian packages is always a Debian-based environment. While Alpine-based containers are nice because of their small size and fast setup times, they introduce a number of issues, two of which are particularly troublesome:
- they use Busybox, where Debian packages rely on the GNU variants of most tools (e.g.
taras you discovered); - most importantly, they use musl, where Debian defaults to glibc.
Both of these can be worked around, but by the time you do that youâÂÂve lost the advantage of a small Alpine container, compared to a minimal Debian container (such as bitnami/minideb as you mentioned).
Note that if youâÂÂre running a Debian derivative on your development and/or build systems, you can skip the container stage entirely, while still using a contained build environment, by using pbuilder. For maximum speed, mount a tmpfs on /var/cache/pbuilder/build, and run the build with eatmydata. sbuild and cowbuilder are also worth looking into, especially if you regularly build similar packages.
As an aside, instead of building binary packages using dpkg-deb -b, I highly recommend learning how to build source packages; start with Vincent BernatâÂÂs pragmatic Debian packaging, itâÂÂs nice and easy.
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
add a comment |Â
up vote
4
down vote
accepted
The best environment in which to build Debian packages is always a Debian-based environment. While Alpine-based containers are nice because of their small size and fast setup times, they introduce a number of issues, two of which are particularly troublesome:
- they use Busybox, where Debian packages rely on the GNU variants of most tools (e.g.
taras you discovered); - most importantly, they use musl, where Debian defaults to glibc.
Both of these can be worked around, but by the time you do that youâÂÂve lost the advantage of a small Alpine container, compared to a minimal Debian container (such as bitnami/minideb as you mentioned).
Note that if youâÂÂre running a Debian derivative on your development and/or build systems, you can skip the container stage entirely, while still using a contained build environment, by using pbuilder. For maximum speed, mount a tmpfs on /var/cache/pbuilder/build, and run the build with eatmydata. sbuild and cowbuilder are also worth looking into, especially if you regularly build similar packages.
As an aside, instead of building binary packages using dpkg-deb -b, I highly recommend learning how to build source packages; start with Vincent BernatâÂÂs pragmatic Debian packaging, itâÂÂs nice and easy.
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
The best environment in which to build Debian packages is always a Debian-based environment. While Alpine-based containers are nice because of their small size and fast setup times, they introduce a number of issues, two of which are particularly troublesome:
- they use Busybox, where Debian packages rely on the GNU variants of most tools (e.g.
taras you discovered); - most importantly, they use musl, where Debian defaults to glibc.
Both of these can be worked around, but by the time you do that youâÂÂve lost the advantage of a small Alpine container, compared to a minimal Debian container (such as bitnami/minideb as you mentioned).
Note that if youâÂÂre running a Debian derivative on your development and/or build systems, you can skip the container stage entirely, while still using a contained build environment, by using pbuilder. For maximum speed, mount a tmpfs on /var/cache/pbuilder/build, and run the build with eatmydata. sbuild and cowbuilder are also worth looking into, especially if you regularly build similar packages.
As an aside, instead of building binary packages using dpkg-deb -b, I highly recommend learning how to build source packages; start with Vincent BernatâÂÂs pragmatic Debian packaging, itâÂÂs nice and easy.
The best environment in which to build Debian packages is always a Debian-based environment. While Alpine-based containers are nice because of their small size and fast setup times, they introduce a number of issues, two of which are particularly troublesome:
- they use Busybox, where Debian packages rely on the GNU variants of most tools (e.g.
taras you discovered); - most importantly, they use musl, where Debian defaults to glibc.
Both of these can be worked around, but by the time you do that youâÂÂve lost the advantage of a small Alpine container, compared to a minimal Debian container (such as bitnami/minideb as you mentioned).
Note that if youâÂÂre running a Debian derivative on your development and/or build systems, you can skip the container stage entirely, while still using a contained build environment, by using pbuilder. For maximum speed, mount a tmpfs on /var/cache/pbuilder/build, and run the build with eatmydata. sbuild and cowbuilder are also worth looking into, especially if you regularly build similar packages.
As an aside, instead of building binary packages using dpkg-deb -b, I highly recommend learning how to build source packages; start with Vincent BernatâÂÂs pragmatic Debian packaging, itâÂÂs nice and easy.
answered Jun 15 at 7:46
Stephen Kitt
139k22301363
139k22301363
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
add a comment |Â
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
Amazing answer, above and beyond! I will have a look at the guide and see if I can improve my build process based on it.
â hochas
Jun 15 at 12:22
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f449939%2fbuilding-deb-on-alpine%23new-answer', 'question_page');
);
Post as a guest
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
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
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
WhatâÂÂs the basic problem youâÂÂre trying to solve by building the package in an Alpine-based Docker container? (There are a number of issues with this approach, including the use of Busybox, and more importantly the use of musl instead of glibc. They can be surmounted but IâÂÂd rather understand what youâÂÂre really trying to do before going into all that...)
â Stephen Kitt
Jun 15 at 7:03
@StephenKitt I mostly seek the minimal image size that Alpine gives, it allows me to run builds a lot faster. I tried swapping alpine to
bitnami/minideband it works, as expected. So if I understand you right I shouldn't bother?â hochas
Jun 15 at 7:12