X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by lists.alpinelinux.org (Postfix) with ESMTP id 3F0F6360F71C for ; Tue, 2 Mar 2010 07:21:42 +0000 (UTC) Received: by ewy21 with SMTP id 21so224248ewy.25 for ; Mon, 01 Mar 2010 23:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bNQXSVspPBe4iFhATKptd+QCAxoSW6aUqZ7y7cKw0wg=; b=aYdSQswGj2ebMGh1w7HiMwUfdIo9N4ppJkYyylTltNxaW6OnDM2FyoWRX1UbVtxNgW gcngKo5GOrzKo28A4SX+nE9+73VmoRSF3Lr4eA3KNjysJmOwynQ7AxJl9eR/8jzKihXm bRC+Vql96sPFLA3yKUStuV0f2GzXYwbnvuui0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ryu1e6W+iZen5J7Tc6si3OX1MhNUSjOr/8sKDnQ2kdt0qTjgq+ub/JrZAAHqc5Ph// BOh/gihwAmo719k5s2lxYcbkrVjdX4D/u8S0hHRuaV8a3DqdH0ETHBUdtXOyNnlQ8AkT KtN7VGW316Oq6OESAafn7b3x1Ls0qnGrZKA6c= X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.213.65.204 with SMTP id k12mr661876ebi.4.1267514501371; Mon, 01 Mar 2010 23:21:41 -0800 (PST) Date: Tue, 2 Mar 2010 08:21:41 +0100 Message-ID: <95408c821003012321j22b36b8fk1130a838f32fa9b6@mail.gmail.com> Subject: [alpine-devel] apk-tools idea: binding to other applications and languages From: Natanael Copa To: Alpine Developers Content-Type: text/plain; charset=ISO-8859-1 Hi, 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) -- Natanael Copa --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---