DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=vGJZsxuViWExUaZzaHWtl9FXfQXEoskvYVJYB1hPvQPBSehi99TXQDYBkSuDE6H79M
         WRhzB8unTGfU0f4xM+a9LgwDIvd68pA8fzZ1viQ6Z4QnTkABZBAtDUqAU9ySFQrxr22b
         2OPAIyx2Jv0JDJoQHP2FLZI4PHHAov2hYwBWg=
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Message-ID: <4B8CDDFE.2090202@iki.fi>
Date: Tue, 02 Mar 2010 11:44:30 +0200
From: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
Precedence: list
MIME-Version: 1.0
To: Natanael Copa <natanael.copa@gmail.com>
CC: Alpine Developers <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] apk-tools idea: binding to other applications
 and languages
References: <95408c821003012321j22b36b8fk1130a838f32fa9b6@mail.gmail.com>
In-Reply-To: <95408c821003012321j22b36b8fk1130a838f32fa9b6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Natanael Copa wrote:
> Som things I have been thinking of for some time.
> 
> It would be nice to make apk-tools functions available from other
> applications and higher level languages. The immedeate need I have is
> a binding to the version compare functions from lua. In the longer run
> it would be nice to be able to make a gui installer and have a nice
> gui progress bar while installing. The point is that we will sooner or
> later need to bind to apk from other applications.
> 
> We have some alternatives:
> 1. we can make a dynamic libapk.so and have the apk application link
> to it and have the lua apk.so to link to it too. Less dupe of code.
> 2. we can dup the code. A build target uses same code but builds a lua
> apk.so or similar.
> 3. we can have lua library fork/exec the current apk and parse the
> output. I don't like this, specially not for sorting scripts that
> needs compare version strings.
> 
> When it comes to the initramfs installer, we already need libcrypto,
> libz, libc and openssl (for encrypted apkovls) in the initramfs image
> so adding another lib doesnt really matter. (we could make an initapk
> tool which links libc and libapk statically but libcrypt and libc
> dynamic)

>From size point of view, option 1 is best. Though, currently apk
library will not be that large so option 2 is ok too. Option 3 is
not a good idea from performance point of view.

However 1&2 do require that we start to maintain some sort of
stable API. At least for the high level stuff the lua code wants
to do.

But sounds good to me.

- Timo




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---