Message-ID: <4A702C37.2010003@renta.net>
Date: Wed, 29 Jul 2009 21:02:15 +1000
From: Mark Constable <markc@renta.net>
User-Agent: Thunderbird 2.0.0.22 (X11/20090719)
Precedence: list
MIME-Version: 1.0
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Getting started
References: <4A6F72FF.9040702@renta.net> <4A6FDA87.6090002@iki.fi>
In-Reply-To: <4A6FDA87.6090002@iki.fi>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Timo Ter=E4s wrote:
>> Somewhere someone mentioned something about Alpine moving towards
>> Archs' pacman/makepkg... is this true?
>=20
> When alpine 1.9 development was started one major thing to change
> was package manager as the shell script based apk-tools was too
> slow.

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.

> Arch's pacman was a strong candidate to switch to. And we
> did talk about that in various places. Eventually we decided to
> rewrite apk-tools in C. I think ncopa had some issues with
> makepkg too, and that's why he ended up writing abuild.

makepkg from pacman 3.3 has had some posix love. I'm torn between
the established package base (albeit glibc based) and the lightness
and next-gen feel of apk.

> Pacman would have needed customization, as alpine's feature to
> "boot from cdrom, read overlay from usb/floppy and install packages
> from cdrom to root tmpfs" is relatively unique.

Thanks for the pointer, I have much to learn about Alpine.

> I also remember
> that we would have needed to change the internal database format
> to some degree, to get better memory usage on a tmpfs root.

Which would have been nice to get into Arch, but anyways, perhaps
it was easier to start from a clean slate.

> Granted, we could have probably patched / forked pacman for our
> needs. But we saw the migration path easier this way.

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.

I have some very tight guidelines for a busybox/javascript based
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).

> - Timo

Thanks you so much for this info, very much appreciated.

--markc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---