Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Mon, 2 Feb 2015 11:17:18 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Orion <systmkor@gmail.com>
Cc: "alpine-devel@lists.alpinelinux.org"
 <alpine-devel@lists.alpinelinux.org>
Subject: [alpine-devel] Re: apk-tools - In need of a minimal spec
Message-ID: <20150202111718.66140f1d@vostro>
In-Reply-To: <20150202003218.6209a4a2@twinpeaks.my.domain>
References: <20150202003218.6209a4a2@twinpeaks.my.domain>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 2 Feb 2015 00:32:18 -0800
Orion <systmkor@gmail.com> wrote:

> I have began reading through the apk-tools source code with the goal
> of teaching myself more about how package managers work by porting
> it into go-lang. I would appreciate help compiling some minimally
> sufficient specification for this.
> 
> I ask for your help because I have had little luck finding any kind of
> documentation, design thoughts, comments, or self describing
> functions/variables. Let me know what the easiest means of discussion
> would be.

Yes, we should add some overview documentation. And specs of how the
package format is handled.

> # Stuff I Found Confusing
>  * blob.c
> 	* memspn()
> 	* memcspn()
> 	* apk_blob_spn()
> 	* apk_blob_cspn()

It's basically similar to strspn() but with two differences:
 - it works with blobs, so the source string is not zero-terminated
 - the list of characters to accept or reject is a bitmap instead of
   zero-terminated string (see the header for apk_spn_match_def typedef)

memspn() would probably be the libc name, but there is no such
function. Use of that name is probably misleading.

I wrote this earlier when I had tendency to micro-optimize things. If
I'd write it now, I'd leave the memspn() stuff out, and keep only the
C-versions.

> 	* digitdecode & dx()
> 		- is data taken, encoded with your own custom codec

This is just a lookup-table based ASCII hexnumber to number conversion.
Basically atoi() and strtol() equivalent, but it's hand written again,
so we can work with "blobs" (length limited, not zero-terminated).

> and then put into a blow?
>  * archive.c & gunzip.c
> 	* is the tar and gzip code used custom or pulled from existing
> 	  implementations?

gunzip.c ends up using libz. It's just glue for the internal
abstractionlayer.

archive.c contains full tar decoder and encoder. It's mostly custom
code. And currently it is required due to how the .apk file is
constructed.

/Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---