Mark Constable wrote:
> Timo Teräs wrote:
>>> Somewhere someone mentioned something about Alpine moving towards
>>> Archs' pacman/makepkg... is this true?
>> When alpine 1.9 development was started one major thing to change
>> was package manager as the shell script based apk-tools was too
> Okay, so pre-1.9 is an ash based system? I'll have to look into
> that as I suspect most of the speed penalty is from not using
> an SQLite database for all meta-info. Just guessing.
Yes, and the fact that it had to fork/exec hundreds of times
during installation of all packages (to exec: tar, gz, various
scripts, etc. etc) and that shell scripts are interpreted.
Alpine 1.9 series has apk-tools that is generally one big
executable that forks only to execute package post/pre install
scripts. Also apk-tools link to libz and has tar parsing code,
so there's no extra penalty piping data through unix sockets.
Generally the new code always mmap()s everything and extracts
inplace, so it's pretty fast. Checksumming is done simultaneously
so the archives are read generally only once.
The new code also uses openssl for checksumming so it automatically
uses hardware acceleration if available (e.g. padlock for SHA1
stuff if openssl is patched).
> Right. There would be no point if the current base of Arch packages
> were not compatible and reusable. Seeing Alpine is uclibc based
> then just about all Arch packages need to be rebuilt anyway.
> My apologies for not going through whatever mailing-list archives
> there are to research these basic points. I was in the process of
> building a busybox/uclibc/scratchbox system for Arch when I found
> out about Alpine just a few days ago.
Yeah, we should fix the mailing lists to be easer to use.
> desktop distro and, so far, Alpine looks much closer to where I
> want to be than Arch (which IMVHO leaves deb/rpm in the dust).
If you want anything uclibc+bb based, I suggest to seriously
consider Alpine. I've spent quite a bit of time of hunting
uclibc/bb/other related bugs. Some fixes are custom for Alpine.
E.g. uclibc has a lot of threading related things fixed.
The group is not too large, so there's no complicated politics
involved to get patches and new stuff included. But it is large
enough to get things done :)
Received on Wed Jul 29 2009 - 14:12:19 UTC