Subject: [alpine-devel] Getting started

From: Mark Constable <[email-masked]>
Date: Wed, 29 Jul 2009 07:51:59 +1000

Hi, I presume this is the best place to discuss Alpine issues?

Is there a mailing-list archive or a normal bbs/forum?

Somewhere someone mentioned something about Alpine moving towards
Archs' pacman/makepkg... is this true?

Thanks for any help.

--markc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 29 Jul 2009 10:25:12 +0200

> Is there a mailing-list archive or a normal bbs/forum?

btw...

Since we have redmine running, and since we are fairly satisfied with it
and it is easy to enable a normal forum: Do we want enable a forum for
general discussion?

-nc

---

---

From: Mark Constable <[email-masked]>
Date: Wed, 29 Jul 2009 20:35:32 +1000

> and it is easy to enable a normal forum: Do we want enable a forum for

A google group is very flexible, extremely searchable and provides
the end user with good web based management. I'm so used to mailman
based list management that it was a bit of shock to sign up to this
list.

--markc

---

---

From: Nathan Angelacos <[email-masked]>
Date: Wed, 29 Jul 2009 10:22:23 -0400

> and it is easy to enable a normal forum: Do we want enable a forum for
I thought that's what #alpine-devel on irc.freenode.net was for...

---

---

From: Nathan Angelacos <[email-masked]>
Date: Tue, 28 Jul 2009 20:38:26 -0700

Hi Mark,

> Hi, I presume this is the best place to discuss Alpine issues?

Yup this is the place.  Welcome!

> Is there a mailing-list archive or a normal bbs/forum?

The mailing list archive is here:

http://lists.alpinelinux.org/alpine-devel/

(Sorry, no indexing - its on the (long) todo list)

> Archs' pacman/makepkg... is this true?

Um.. I think the current plan is "apk version 42" or something like 
that. The latest that's being worked on is signed packages.

http://wiki.alpinelinux.org/w/index.php?title=Apkindex_format

has natanel's notes on the latest changes.  I have some notes on the 
various package formats that have been used; it needs to be posted on 
the wiki, but I haven't gotten a chance to do so :-(

> Thanks for any help.

Sure, although I'm not sure this is much help.   If you don't mind, drop 
me a line of what info you'd like to see, or is missing - I'm supposed 
to be the infrastructure/documentation guy - so your impressions will be 
very helpful.

(And, I hope we can answer your questions, as well.)

---

---

From: Timo Teräs <[email-masked]>
Date: Wed, 29 Jul 2009 08:13:43 +0300

Hi Mark,

> 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
slow. 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.

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

Granted, we could have probably patched / forked pacman for our
needs. But we saw the migration path easier this way.

- Timo

---

---

From: Mark Constable <[email-masked]>
Date: Wed, 29 Jul 2009 21:02:15 +1000

Timo Teräs wrote:
> 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

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.

> from cdrom to root tmpfs" is relatively unique.

Thanks for the pointer, I have much to learn about Alpine.

> I also remember

Which would have been nice to get into Arch, but anyways, perhaps
it was easier to start from a clean slate.

> 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

---

---

From: Timo Teräs <[email-masked]>
Date: Wed, 29 Jul 2009 14:12:19 +0300

> 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).

>[snip]

Correct.

> out about Alpine just a few days ago.

Yeah, we should fix the mailing lists to be easer to use.

> 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 :)

- Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 29 Jul 2009 13:43:58 +0200

> out about Alpine just a few days ago.

No. Its not your fault there was no easy way to find the archives.
I added links to the archives for next man. Thanks!

> want to be than Arch (which IMVHO leaves deb/rpm in the dust).

fwiw, I was thinking of starting up an alpine-desktop subproject but I
have not been sure if there is any interest of such thing and I know for
sure I'm at the limit of what I can handle alone.

I have got most parts of xorg and xfce running, using evenings and
weekends. I'm using alpine with xfce on my hp 2133. (which has padlock
and benefit from the openssl patches. yay!). I have midori browser,
xchat, terminal, rdeskop, the basic stuff. If I get atleast one more
person to work on alpine-desktop I say its a go!

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 29 Jul 2009 08:47:53 +0200

> makepkg too, and that's why he ended up writing abuild.

Basicly, i wanted get rid of the bash dependency and we want to split
the packages so docs and dev files (headers, .a etc) are in separate
packages. Thats why we could not use the ABS from arch linux.

That said, abuild is very much inspired of makepkg and gentoo's ebuild.
The APKBUILDS are very similar PKGBUILD and we often use the PKGBUILD as
base for our packages.

Thanks!

-nc

---