Building .deb on Alpine

The name of the pictureThe name of the pictureThe name of the pictureClash 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?







share|improve this question



















  • 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














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?







share|improve this question



















  • 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












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?







share|improve this question











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?









share|improve this question










share|improve this question




share|improve this question









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 to bitnami/minideb and 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










  • @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















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










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. tar as 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.






share|improve this answer





















  • 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










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',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















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






























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. tar as 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.






share|improve this answer





















  • 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














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. tar as 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.






share|improve this answer





















  • 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












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. tar as 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.






share|improve this answer













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. tar as 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.







share|improve this answer













share|improve this answer



share|improve this answer











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
















  • 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












 

draft saved


draft discarded


























 


draft saved


draft discarded














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













































































Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)