[opensuse-buildservice] AlpineLinux and OBS
This is just to raise the question to simply initiate a discussion, why not have AlpineLinux on OBS too? On the positive side, it should be relatively easy to adapt since it is really rather similar to Arch, which is already supported on OBS, but simpler. On the other hand, unlike Arch, it also has 6 month releases that are supported for 2 years. I do appreciate those would accumulate over time. It also has a lot more architectures supported. So I do appreciate that it could also become a maintenance time sink in OBS. Also, I have no sense of the real size of the AlpineLinux using community, and I suspect most use it from the docker and container perspective, which is a valid and potential community that could benefit from OBS. In my particular case, I do use Alpine very broadly, and specifically for headless arm/IoT devices.-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Dienstag, 31. Dezember 2019, 15:01:54 CET David Sugar wrote:
This is just to raise the question to simply initiate a discussion, why not have AlpineLinux on OBS too?
On the positive side, it should be relatively easy to adapt since it is really rather similar to Arch, which is already supported on OBS, but simpler.
On the other hand, unlike Arch, it also has 6 month releases that are supported for 2 years. I do appreciate those would accumulate over time. It also has a lot more architectures supported. So I do appreciate that it could also become a maintenance time sink in OBS.
Also, I have no sense of the real size of the AlpineLinux using community, and I suspect most use it from the docker and container perspective, which is a valid and potential community that could benefit from OBS. In my particular case, I do use Alpine very broadly, and specifically for headless arm/IoT devices.--
IIRC it uses it's own package format, right?
You could add the support following this HOWTO:
https://github.com/openSUSE/obs-build/blob/master/HOWTO.add_another_format
--
Adrian Schroeter
Hi Adrian, The one plus side is it is rather similar to arch. It uses an APKBUILD file which basically is very much like an arch PKGBUILD. It has an abuild tool which is like makepkg, packages are essentially tar files named .apk, and abuild directly builds to/will update a destination archive which, like arch, is an archive file of apk pkgs and index file, with directories split by architecture. It also has a flat gpg key store for signing keys in a separate directory with each key in a separate file. I suspect it would mostly require reworking existing arch support in slight and subtle ways. If you have worked with arch packaging, Alpine feels and operates really very similar. I think the natural starting point is for me is to look at the existing Arch support as well as that howto. One key reason why someone might choose Alpine vs Arch is system size. Alpine uses musl rather than glibc and busybox provides core tools. This leads to very small boot images as well as tiny container images. Another unique aspect of Alpine is it can be used in a pure ramdisk boot installation that can be rewritten to disk on demand, which is nice for sd cards where you don’t wear level during operation, or flash boot. Finally, static builds are easily supported in Alpine, too, so I sometimes use it to generate c++ pure static binaries to run on foreign bistro targets, using ansible to install them on Debian or openSUSE cloud servers. So it has unique niches that are rather useful and different than most other distros. I am finding it rather complimentary to what I do with openSUSE.
On Jan 2, 2020, at 3:11 AM, Adrian Schröter
wrote: On Dienstag, 31. Dezember 2019, 15:01:54 CET David Sugar wrote:
This is just to raise the question to simply initiate a discussion, why not have AlpineLinux on OBS too?
On the positive side, it should be relatively easy to adapt since it is really rather similar to Arch, which is already supported on OBS, but simpler.
On the other hand, unlike Arch, it also has 6 month releases that are supported for 2 years. I do appreciate those would accumulate over time. It also has a lot more architectures supported. So I do appreciate that it could also become a maintenance time sink in OBS.
Also, I have no sense of the real size of the AlpineLinux using community, and I suspect most use it from the docker and container perspective, which is a valid and potential community that could benefit from OBS. In my particular case, I do use Alpine very broadly, and specifically for headless arm/IoT devices.--
IIRC it uses it's own package format, right?
You could add the support following this HOWTO:
https://github.com/openSUSE/obs-build/blob/master/HOWTO.add_another_format
--
Adrian Schroeter
Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2020-01-02 14:12, David Sugar wrote:
[...] busybox provides core tools. This leads to very small boot images [...]
Re. the size of core tools, i.e., busybox vs. GNU coreutils: You can decrease the size of a GNU coreutils installation by: - removing documentation (questionable): 276K /usr/share/doc/packages/coreutils 224K /usr/share/info/coreutils.info.gz 424K /usr/share/man/man1/* - building without NLS support (via 'configure --disable-nls'): $ du -shx cu-regular/inst* 45M cu-regular/inst 36M cu-regular/inst-no-nls - by building as a single 'coreutils' binary (like busybox) with the 'configure' option "--enable-single-binary=shebangs|symlinks": $ ./configure --help ... --enable-single-binary=shebangs|symlinks Compile all the tools in a single binary, reducing the overall size. When compiled this way, shebangs (default when enabled) or symlinks are installed for each tool that points to the single binary. That option reduces the size of a GNU coreutils installation (including all documentation, no RPM package info) from 45M to 18M: # Regular GNU coreutils installation: du -hs cu-regular/inst 45M cu-regular/inst # GNU coreutils installation built with '--enable-single-binary=shebangs': du -hs cu-shebang/inst 18M cu-shebang/inst # GNU coreutils installation built with '--enable-single-binary=symlinks': du -hs cu-symlink/inst 18M cu-symlink/inst Combined with the above --disable-nls, this makes tiny ~8M (still including the man pages and the info page!): $ du -hs cu-symlink/inst-no-nls cu-shebang/inst-no-nls 7.9M cu-symlink/inst-no-nls 8.3M cu-shebang/inst-no-nls The single-binary 'coreutils' executable takes 6.5M of that. Of course, this still includes the full GNU coreutils functionality we're used to. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Jan 2, 2020 at 12:06 PM Bernhard Voelker
On 2020-01-02 14:12, David Sugar wrote:
[...] busybox provides core tools. This leads to very small boot images [...]
Re. the size of core tools, i.e., busybox vs. GNU coreutils:
You can decrease the size of a GNU coreutils installation by:
- removing documentation (questionable): 276K /usr/share/doc/packages/coreutils 224K /usr/share/info/coreutils.info.gz 424K /usr/share/man/man1/*
- building without NLS support (via 'configure --disable-nls'):
$ du -shx cu-regular/inst* 45M cu-regular/inst 36M cu-regular/inst-no-nls
- by building as a single 'coreutils' binary (like busybox) with the 'configure' option "--enable-single-binary=shebangs|symlinks":
$ ./configure --help ... --enable-single-binary=shebangs|symlinks Compile all the tools in a single binary, reducing the overall size. When compiled this way, shebangs (default when enabled) or symlinks are installed for each tool that points to the single binary.
That option reduces the size of a GNU coreutils installation (including all documentation, no RPM package info) from 45M to 18M:
# Regular GNU coreutils installation: du -hs cu-regular/inst 45M cu-regular/inst
# GNU coreutils installation built with '--enable-single-binary=shebangs': du -hs cu-shebang/inst 18M cu-shebang/inst
# GNU coreutils installation built with '--enable-single-binary=symlinks': du -hs cu-symlink/inst 18M cu-symlink/inst
Combined with the above --disable-nls, this makes tiny ~8M (still including the man pages and the info page!):
$ du -hs cu-symlink/inst-no-nls cu-shebang/inst-no-nls 7.9M cu-symlink/inst-no-nls 8.3M cu-shebang/inst-no-nls
The single-binary 'coreutils' executable takes 6.5M of that. Of course, this still includes the full GNU coreutils functionality we're used to. ;-)
This trick is actually employed in Fedora with the coreutils-single package. It's quite handy. :) -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2020-01-02 18:22, Neal Gompa wrote:
This trick is actually employed in Fedora with the coreutils-single package. It's quite handy. :)
I know - I'm in contact with Kamil - the Fedora coreutils maintainer - from time to time. ;-) Do we need a 'coreutils-single' package at openSUSE as well? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Jan 3, 2020 at 4:05 AM Bernhard Voelker
On 2020-01-02 18:22, Neal Gompa wrote:
This trick is actually employed in Fedora with the coreutils-single package. It's quite handy. :)
I know - I'm in contact with Kamil - the Fedora coreutils maintainer - from time to time. ;-)
Do we need a 'coreutils-single' package at openSUSE as well?
It'd be better than using busybox for the minimal openSUSE container... -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
From the existing openSUSE perspective that is probably true, rather than reworking around using busy box. It would also be nice for other JeOS images, too, especially to get a more reasonable minimal headless JeOS arm image (currently it expands to >2G).
On Jan 3, 2020, at 5:22 AM, Neal Gompa
wrote: On Fri, Jan 3, 2020 at 4:05 AM Bernhard Voelker
wrote: On 2020-01-02 18:22, Neal Gompa wrote:
This trick is actually employed in Fedora with the coreutils-single package. It's quite handy. :)
I know - I'm in contact with Kamil - the Fedora coreutils maintainer - from time to time. ;-)
Do we need a 'coreutils-single' package at openSUSE as well?
It'd be better than using busybox for the minimal openSUSE container...
-- 真実はいつも一つ!/ Always, there's only one truth!
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2020-01-04 19:48, David Sugar wrote:
Do we need a 'coreutils-single' package at openSUSE as well?
It'd be better than using busybox for the minimal openSUSE container...
Available since Tumbleweed snapshot 20200213 release. Kudos to Ludwig! Have fun, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (4)
-
Adrian Schröter
-
Bernhard Voelker
-
David Sugar
-
Neal Gompa