~alpine/devel

9 4

[alpine-devel] Getting started

Mark Constable <markc@renta.net>
Details
Message ID
<4A6F72FF.9040702@renta.net>
Sender timestamp
1248817919
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Nathan Angelacos <nangel@nothome.org>
Details
Message ID
<4A6FC432.4070105@nothome.org>
In-Reply-To
<4A6F72FF.9040702@renta.net> (view parent)
Sender timestamp
1248838706
DKIM signature
missing
Download raw message
Hi Mark,

Mark Constable wrote:
> 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)


> Somewhere someone mentioned something about Alpine moving towards
> 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.)



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4A6FDA87.6090002@iki.fi>
In-Reply-To
<4A6F72FF.9040702@renta.net> (view parent)
Sender timestamp
1248844423
DKIM signature
missing
Download raw message
Hi Mark,

Mark Constable 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
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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<1248850074.9222.5.camel@localhost.localdomain>
In-Reply-To
<4A6FDA87.6090002@iki.fi> (view parent)
Sender timestamp
1248850073
DKIM signature
missing
Download raw message
On Wed, 2009-07-29 at 08:13 +0300, Timo Teräs wrote:
> Hi Mark,
> 
> Mark Constable 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
> 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.

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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Nathan Angelacos <nangel@nothome.org>
Details
Message ID
<4A705B1F.3030907@nothome.org>
In-Reply-To
<1248855912.9222.10.camel@localhost.localdomain> (view parent)
Sender timestamp
1248877343
DKIM signature
missing
Download raw message
Natanael Copa wrote:
> On Wed, 2009-07-29 at 07:51 +1000, Mark Constable wrote:
>> Hi, I presume this is the best place to discuss Alpine issues?
>>
>> 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?
> 
I thought that's what #alpine-devel on irc.freenode.net was for...


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<1248855912.9222.10.camel@localhost.localdomain>
In-Reply-To
<4A6F72FF.9040702@renta.net> (view parent)
Sender timestamp
1248855912
DKIM signature
missing
Download raw message
On Wed, 2009-07-29 at 07:51 +1000, Mark Constable wrote:
> Hi, I presume this is the best place to discuss Alpine issues?
> 
> 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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<1248867838.9222.21.camel@localhost.localdomain>
In-Reply-To
<4A702C37.2010003@renta.net> (view parent)
Sender timestamp
1248867838
DKIM signature
missing
Download raw message
On Wed, 2009-07-29 at 21:02 +1000, Mark Constable wrote:

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

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

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

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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4A702E93.4070606@iki.fi>
In-Reply-To
<4A702C37.2010003@renta.net> (view parent)
Sender timestamp
1248865939
DKIM signature
missing
Download raw message
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
>> 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.

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

Correct.

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

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

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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Mark Constable <markc@renta.net>
Details
Message ID
<4A7025F4.8010706@renta.net>
In-Reply-To
<1248855912.9222.10.camel@localhost.localdomain> (view parent)
Sender timestamp
1248863732
DKIM signature
missing
Download raw message
Natanael Copa wrote:
> 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?

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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Mark Constable <markc@renta.net>
Details
Message ID
<4A702C37.2010003@renta.net>
In-Reply-To
<4A6FDA87.6090002@iki.fi> (view parent)
Sender timestamp
1248865335
DKIM signature
missing
Download raw message
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
> 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
---
Reply to thread Export thread (mbox)